64Mbytes on Sandpoint-X3B

64Mbytes on Sandpoint-X3B

[Sergiy Kovtun]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4633 bytes --]


Hello All,
I try to connect all my 64 Meg memoty on
Sandpoint-X3B,
but received a crash( with 32M all OK).
Source:
SP-X3B + Altimus MPC7410
HHL 2.0
Any ideas??

TIA,
Sergiy

go 90000
loaded at:     00090000 000991B8

relocated to:  00800000 008091B8

zimage at:     00096000 001387F9

relocated to:  0080A000 008AC7F9

avail ram:     00400000 00800000


Linux/PPC load: console=ttyS0,9600 console=tty0
root=/dev/hdb2 ip=210.222.86.67:::255.255.255.192
Uncompressing Linux...done.
Now booting the kernel
Total memory = 64MB; using 256kB for hash table (at
c01c0000)
Linux version 2.4.2_hhl20 (root@sergiy) (gcc version
2.95.3 20010315 (release/MontaVista)) #2 Thu May 23
16:34:36 KST 2002
Motorola SPS Sandpoint Test Platform
Sandpoint port (C) 2000, 2001 MontaVista Software,
Inc. (source@mvista.com)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 console=tty0
root=/dev/hdb2 ip=210.222.86.67:::255.255.255.192
OpenPIC Version 1.2 (1 CPUs and 24 IRQ sources) at
f7fd0000
OpenPIC timer frequency is 100.000000 MHz
time_init: decrementer frequency = 24.359871 MHz
Calibrating delay loop... 389.12 BogoMIPS
Memory: 62388k available (1108k kernel code, 416k
data, 192k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536
bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384
bytes)
Page-cache hash table entries: 16384 (order: 4, 65536
bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768
bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society
NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41389kB/13796kB, 128
slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
W82C105: IDE controller on PCI bus 00 dev 59
W82C105: chipset revision 5
W82C105: 100% native mode on irq 17
    ide0: BM-DMA at 0xbfffd0-0xbfffd7, BIOS settings:
hda:pio, hdb:pio
SL82C105 command word: 5
IDE timing: 00000909, resetting to PIO0 timing
    ide1: BM-DMA at 0xbfffd8-0xbfffdf, BIOS settings:
hdc:pio, hdd:pio
SL82C105 command word: 5
IDE timing: 000003e4, resetting to PIO0 timing
hdb: QUANTUM FIREBALL EX6.4A, ATA DISK drive
ide0 at 0xbffff8-0xbfffff,0xbffff6 on irq 14
hdb: 12594960 sectors (6449 MB) w/418KiB Cache,
CHS=13328/15/63
Partition check:
 hdb: [PTBL] [784/255/63] hdb1 hdb2 hdb3 < hdb5 >
loop: loaded (max 8 devices)
Serial driver version 5.02 (2000-08-09) with
MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled
ÿttyS00 at 0x03f8 (irq = 0) is a 16550A
ttyS01 at 0x02f8 (irq = 0) is a 16550A
3c59x.c:LK1.1.12 06 Jan 2000  Donald Becker and
others. http://www.scyld.com/network/vortex.html
$Revision: 1.102.2.46 $
See Documentation/networking/vortex.txt
eth0: 3Com PCI 3cSOHO100-TX Hurricane at 0xbfff00,
00:04:76:d0:1c:56, IRQ 18
  product code 'MM' rev 00.12 date 11-02-01
  8K byte-wide RAM 5:3 Rx:Tx split,
autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 786d.
  Enabling bus-master transmits and whole-frame
receives.
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
4096)
eth0: using NWAY autonegotiation
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 192k init 4k
openfirmware
Oops: kernel access of bad area, sig: 11
NIP: C002B8E8 XER: 20000000 LR: C002B8BC SP: C0319B30
REGS: c0319a80 TRAP: 0300
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: C6024078, DSISR: 40000000
TASK = c0318000[1] 'init' Last syscall: 6
last math c0318000 last altivec 00000000
GPR00: 00001032 C0319B30 C0318000 00000001 00009032
C0319B18 C0319B38 C3FE4000
GPR08: C0810018 C6024060 C0810018 000000A0 000493E0
00000000 7FFFFA40 3002A228
GPR16: 3002A5C8 00000001 0000013B C034E560 C03EF5A0
C0319B98 00000000 00000001
GPR24: 00000000 C034E560 C0362400 00000002 C0319B38
C0140000 C0144620 C0315444
Call backtrace:
C00CB140 C00CFE00 C00D6064 C00D62DC C00D807C C00CDFE0
C0017128
C0003DA8 C001CAEC C001CC28 C000EA64 C0003D64 3000CB48
30004D30
30010EEC 30003880 300037AC 3001331C
Kernel panic: Aiee, killing interrupt handler

In interrupt handler - not syncing
Rebooting in 180 seconds..


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

Re: 64Mbytes on Sandpoint-X3B

[Tom Rini]

On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:

> Hello All,
> I try to connect all my 64 Meg memoty on
> Sandpoint-X3B,
> but received a crash( with 32M all OK).
> Source:
> SP-X3B + Altimus MPC7410
> HHL 2.0
> Any ideas??

DINK32 12.2 does not correctly initalize the memory controller on-board.
DINK32 12.3 claims to do this correctly, but in some testing locally it
still did not get everything correct.

There's a chance that PPCBoot does get this right, however.  But I'm no
PPCBoot expert.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: 64Mbytes on Sandpoint-X3B

[Jim Thompson]

Tom Rini writes:
>
> On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
>
> > Hello All,
> > I try to connect all my 64 Meg memoty on
> > Sandpoint-X3B,
> > but received a crash( with 32M all OK).
> > Source:
> > SP-X3B + Altimus MPC7410
> > HHL 2.0
> > Any ideas??
>
> DINK32 12.2 does not correctly initalize the memory controller on-board.
> DINK32 12.3 claims to do this correctly, but in some testing locally it
> still did not get everything correct.

Could you be more specific as to what is missing?

> There's a chance that PPCBoot does get this right, however.  But I'm no
> PPCBoot expert.

I don't know about the 74xx support in PPCBoot, but PPCBoot sets up
the 107 in a MCP8245 on a Sandpoint X3 well-enough to boot linux.
PPCboot does not, however, configure more than one 'bank' on the
SO-DIMM socket, and does not (currently) read the SPDs, if only for
the lack of proper I2C support (at least for the 824x).

YMMV.

My question is how have_of got set:

arch/ppc/mm/init.c:
        if (!have_of)
                FREESEC(openfirmware);

Otherwise...

On the whole "'reset/reboot' the system" thread, I'm interested in
similar solutions for the 824x, since I'm having highly similar
problems on reboot. :-)

Interestingly, the 'gorom' solution works fine for me, as long as my
root filesystem is not jffs2, then only if / is mounted 'rw'.

romfs, cramfs, nfs, or jffs2 (read-only) all reboot just fine.

--
"Perl is basically TECO-99."  ---Barry Shein


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

Re: 64Mbytes on Sandpoint-X3B

[Tom Rini]

On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
>
> Tom Rini writes:
> >
> > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
> >
> > > Hello All,
> > > I try to connect all my 64 Meg memoty on
> > > Sandpoint-X3B,
> > > but received a crash( with 32M all OK).
> > > Source:
> > > SP-X3B + Altimus MPC7410
> > > HHL 2.0
> > > Any ideas??
> >
> > DINK32 12.2 does not correctly initalize the memory controller on-board.
> > DINK32 12.3 claims to do this correctly, but in some testing locally it
> > still did not get everything correct.
>
> Could you be more specific as to what is missing?

On the DINK32 12.2 side it blindly sets some parts up for 64mb total
regardless of the ammount of memory.  I think there's other things as
well, but Mark Greer would know better..

For DINK32 12.3 the first problem I've hit is that I can't seem to
convince it to setup the SPD bits on the memory for the 64mb total that seems
to be on the board, only 128mb.  Using DINK32 12.2 and 12.3 to try and
get all of that done 'correctly' still had things blowing up when I
tried to use 64mb.   But I've been busy tracking down other issues at
the moment..

> My question is how have_of got set:
>
> arch/ppc/mm/init.c:
>         if (!have_of)
>                 FREESEC(openfirmware);

On !CONFIG_ALL_PPC, we have:
#define have_of 0
In include/asm-ppc/processor.h, or so.  And the compiler happily
optimizes things in/out with this.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: 64Mbytes on Sandpoint-X3B

[Jim Thompson]

Tom Rini writes:
> On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
> >
> > Tom Rini writes:
> > >
> > > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:

> > My question is how have_of got set:
> >
> > arch/ppc/mm/init.c:
> >         if (!have_of)
> >                 FREESEC(openfirmware);
>
> On !CONFIG_ALL_PPC, we have:
> #define have_of 0
> In include/asm-ppc/processor.h, or so.  And the compiler happily
> optimizes things in/out with this.

I should have been more explicit.

in include/asm-ppc/processor.h, I'd found:

#define have_of (_machine == _MACH_chrp || _machine == _MACH_Pmac)

A sandpoint (esp with Dink) is neither CHRP or PMAC, so the call to
FREESEC(openfirmware) shouldn't have occurred.

Jim

--
"Perl is basically TECO-99."  ---Barry Shein


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

Re: 64Mbytes on Sandpoint-X3B

[Tom Rini]

On Fri, May 31, 2002 at 10:20:08AM -0500, Jim Thompson wrote:
>
> Tom Rini writes:
> > On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
> > >
> > > Tom Rini writes:
> > > >
> > > > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
>
> > > My question is how have_of got set:
> > >
> > > arch/ppc/mm/init.c:
> > >         if (!have_of)
> > >                 FREESEC(openfirmware);
> >
> > On !CONFIG_ALL_PPC, we have:
> > #define have_of 0
> > In include/asm-ppc/processor.h, or so.  And the compiler happily
> > optimizes things in/out with this.
>
> I should have been more explicit.
>
> in include/asm-ppc/processor.h, I'd found:
>
> #define have_of (_machine == _MACH_chrp || _machine == _MACH_Pmac)

Thanks for the memory jog :)

Up near the top, we have:
#ifdef CONFIG_ALL_PPC
...
int _machine;
...
#else
#define _machine 0
#endif

So have_of becomes: (0 == 0x4 || 0 == 0x2)

> A sandpoint (esp with Dink) is neither CHRP or PMAC, so the call to
> FREESEC(openfirmware) shouldn't have occurred.

It's !have_of, so we really did want to free the __openfirmware stuff.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: 64Mbytes on Sandpoint-X3B

[Jim Thompson]

Tom Rini writes:

> > A sandpoint (esp with Dink) is neither CHRP or PMAC, so the call to
> > FREESEC(openfirmware) shouldn't have occurred.
>
> It's !have_of, so we really did want to free the __openfirmware stuff.

OK, I get it.

--
"Perl is basically TECO-99."  ---Barry Shein


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

Re: 64Mbytes on Sandpoint-X3B

[Mark A. Greer]

Tom Rini wrote:

> On Fri, May 31, 2002 at 10:20:08AM -0500, Jim Thompson wrote:
> >
> > Tom Rini writes:
> > > On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
> > > >
> > > > Tom Rini writes:
> > > > >
> > > > > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
> >
> > > > My question is how have_of got set:
> > > >
> > > > arch/ppc/mm/init.c:
> > > >         if (!have_of)
> > > >                 FREESEC(openfirmware);
> > >
> > > On !CONFIG_ALL_PPC, we have:
> > > #define have_of 0
> > > In include/asm-ppc/processor.h, or so.  And the compiler happily
> > > optimizes things in/out with this.
> >
> > I should have been more explicit.
> >
> > in include/asm-ppc/processor.h, I'd found:
> >
> > #define have_of (_machine == _MACH_chrp || _machine == _MACH_Pmac)
>
> Thanks for the memory jog :)
>
> Up near the top, we have:
> #ifdef CONFIG_ALL_PPC
> ...
> int _machine;
> ...
> #else
> #define _machine 0
> #endif
>
> So have_of becomes: (0 == 0x4 || 0 == 0x2)
>
> > A sandpoint (esp with Dink) is neither CHRP or PMAC, so the call to
> > FREESEC(openfirmware) shouldn't have occurred.
>
> It's !have_of, so we really did want to free the __openfirmware stuff.

I dunno guys, I think the compiler usually optimizes that all away and you
should never see "openfirmware".  I don't recall ever seeing it print out.  I
think something fishy is going on...

Mark

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

Re: 64Mbytes on Sandpoint-X3B

[Tom Rini]

On Fri, May 31, 2002 at 01:48:24PM -0400, Mark A. Greer wrote:
> Tom Rini wrote:
>
> > On Fri, May 31, 2002 at 10:20:08AM -0500, Jim Thompson wrote:
> > >
> > > Tom Rini writes:
> > > > On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
> > > > >
> > > > > Tom Rini writes:
> > > > > >
> > > > > > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
> > >
> > > > > My question is how have_of got set:
> > > > >
> > > > > arch/ppc/mm/init.c:
> > > > >         if (!have_of)
> > > > >                 FREESEC(openfirmware);
> > > >
> > > > On !CONFIG_ALL_PPC, we have:
> > > > #define have_of 0
> > > > In include/asm-ppc/processor.h, or so.  And the compiler happily
> > > > optimizes things in/out with this.
> > >
> > > I should have been more explicit.
> > >
> > > in include/asm-ppc/processor.h, I'd found:
> > >
> > > #define have_of (_machine == _MACH_chrp || _machine == _MACH_Pmac)
> >
> > Thanks for the memory jog :)
> >
> > Up near the top, we have:
> > #ifdef CONFIG_ALL_PPC
> > ...
> > int _machine;
> > ...
> > #else
> > #define _machine 0
> > #endif
> >
> > So have_of becomes: (0 == 0x4 || 0 == 0x2)
> >
> > > A sandpoint (esp with Dink) is neither CHRP or PMAC, so the call to
> > > FREESEC(openfirmware) shouldn't have occurred.
> >
> > It's !have_of, so we really did want to free the __openfirmware stuff.
>
> I dunno guys, I think the compiler usually optimizes that all away and you
> should never see "openfirmware".  I don't recall ever seeing it print out.  I
> think something fishy is going on...

Er, first, it becomes:
if (1)
So we always 'do it'.  However, all of the __openfirmware code is now
almost never compiled in on !CONFIG_ALL_PPC, so we never see it being
free'd.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: 64Mbytes on Sandpoint-X3B

[Mark A. Greer]

Tom Rini wrote:

> > I dunno guys, I think the compiler usually optimizes that all away and you
> > should never see "openfirmware".  I don't recall ever seeing it print out.  I
> > think something fishy is going on...
>
> Er, first, it becomes:
> if (1)
> So we always 'do it'.  However, all of the __openfirmware code is now
> almost never compiled in on !CONFIG_ALL_PPC, so we never see it being
> free'd.

That was my point.

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

Re: 64Mbytes on Sandpoint-X3B

[Tom Rini]

On Fri, May 31, 2002 at 02:18:57PM -0400, Mark A. Greer wrote:
> Tom Rini wrote:
>
> > > I dunno guys, I think the compiler usually optimizes that all away and you
> > > should never see "openfirmware".  I don't recall ever seeing it print out.  I
> > > think something fishy is going on...
> >
> > Er, first, it becomes:
> > if (1)
> > So we always 'do it'.  However, all of the __openfirmware code is now
> > almost never compiled in on !CONFIG_ALL_PPC, so we never see it being
> > free'd.
>
> That was my point.

Er, but it didn't make any sense. :)
The __openfirmware code does not get optimized away, iirc.  Unless we
lose global functions which don't have any callers..

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

PPCboot+MPC7410+Sandpoint

[Sergiy Kovtun]

Hello all,

Has anybody successfully built ppcboot for
Altimus(MPC7410) on Sandpoint X3B board ?

Thanks,

Sergiy,


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

Re: PPCboot+MPC7410+Sandpoint

[Boo Geum Jung]

Yes, it works.
I worked with include/config_Sandpoint8245.h and cpu/74xx_7xx.

----- Original Message -----
From: "Sergiy Kovtun" <skovtun@yahoo.com>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Monday, June 24, 2002 10:52 AM
Subject: PPCboot+MPC7410+Sandpoint


>
> Hello all,
>
> Has anybody successfully built ppcboot for
> Altimus(MPC7410) on Sandpoint X3B board ?
>
> Thanks,
>
> Sergiy,
>
>
>


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

Re: PPCboot+MPC7410+Sandpoint

[Wolfgang Denk]

In message <00cd01c21bdd$7160d910$3cabfe81@bgjung13> you wrote:
>
> Yes, it works.
> I worked with include/config_Sandpoint8245.h and cpu/74xx_7xx.

Can you please send me your (modified) config file as patch?

Thanks in advance,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Q: What do you get when you cross an ethernet with an income statement?
A: A local area networth.

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

Re: PPCboot+MPC7410+Sandpoint

[Boo Geum Jung]

Of course, I can.
But right now, it's not clear, it conatins some trial codes.
I'll make it clear under ppcboot-1.1.6.
I'll send you then.
In briefly speaking,
I added a line "#define CONFIG_MPC7410          1" in
config_Sandpoint8245.h.
And use files in cpu/74xx_7xx/ direcoty instaed of mpc824x/
I didn't know well how to make new config file(config_Sandpoint7410.h).
So I modified the original files.
I'll find out the way and I'll modify in smart way.

----- Original Message -----
From: "Wolfgang Denk" <wd@denx.de>
To: "Boo Geum Jung" <bgjung@etri.re.kr>
Cc: <linuxppc-embedded@lists.linuxppc.org>
Sent: Tuesday, June 25, 2002 9:19 AM
Subject: Re: PPCboot+MPC7410+Sandpoint


> In message <00cd01c21bdd$7160d910$3cabfe81@bgjung13> you wrote:
> >
> > Yes, it works.
> > I worked with include/config_Sandpoint8245.h and cpu/74xx_7xx.
>
> Can you please send me your (modified) config file as patch?
>
> Thanks in advance,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> Q: What do you get when you cross an ethernet with an income statement?
> A: A local area networth.
>


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

Re: 64Mbytes on Sandpoint-X3B

[Mark A. Greer]

Tom Rini wrote:

> On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
> >
> > Tom Rini writes:
> > >
> > > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
> > >
> > > > Hello All,
> > > > I try to connect all my 64 Meg memoty on
> > > > Sandpoint-X3B,
> > > > but received a crash( with 32M all OK).
> > > > Source:
> > > > SP-X3B + Altimus MPC7410
> > > > HHL 2.0
> > > > Any ideas??
> > >
> > > DINK32 12.2 does not correctly initalize the memory controller on-board.
> > > DINK32 12.3 claims to do this correctly, but in some testing locally it
> > > still did not get everything correct.
> >
> > Could you be more specific as to what is missing?
>
> On the DINK32 12.2 side it blindly sets some parts up for 64mb total
> regardless of the ammount of memory.  I think there's other things as
> well, but Mark Greer would know better..

I only have 12.2 here and it initializes the wrong amount which will cause a
panic if you rely on the getting the amount of memory from how the memory ctlr
regs are set up.

The last time I really looked at what DINK was doing to the mem ctlr was back on
12.0 so my info is stale now.  Sounds like Tom has the most current, detailed
info on what DINK does.  Chances are, Sergiy, is that you'll  have to roll up
your sleeves and dig into it.

Mark


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

Re: 64Mbytes on Sandpoint-X3B

[Gary Milliorn]

"Mark A. Greer" wrote:
>
> Tom Rini wrote:
>
> > On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
> > >
> > > Tom Rini writes:
> > > >
> > > > On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
> > > >
> > > > > Hello All,
> > > > > I try to connect all my 64 Meg memoty on
> > > > > Sandpoint-X3B,
> > > > > but received a crash( with 32M all OK).
> > > > > Source:
> > > > > SP-X3B + Altimus MPC7410
> > > > > HHL 2.0
> > > > > Any ideas??
> > > >
> > > > DINK32 12.2 does not correctly initalize the memory controller on-board.
> > > > DINK32 12.3 claims to do this correctly, but in some testing locally it
> > > > still did not get everything correct.
> > >
> > > Could you be more specific as to what is missing?
> >
> > On the DINK32 12.2 side it blindly sets some parts up for 64mb total
> > regardless of the ammount of memory.  I think there's other things as
> > well, but Mark Greer would know better..
>
> I only have 12.2 here and it initializes the wrong amount which will cause a
> panic if you rely on the getting the amount of memory from how the memory ctlr
> regs are set up.
>
> The last time I really looked at what DINK was doing to the mem ctlr was back on
> 12.0 so my info is stale now.  Sounds like Tom has the most current, detailed
> info on what DINK does.  Chances are, Sergiy, is that you'll  have to roll up
> your sleeves and dig into it.
>
> Mark
>

  12.3 is on the web at:
http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=DINK32


  As for the 128MB issue, the BOM for non-SODIMM boards, such as Altimus
X3B,
was increased to 128MB but the SPD writing code (no SODIMMs, so no
pre-programmed
SPD EEPROMs) still only supports 64MB init values (mi -w).  12.4 is not
done
yet but will init with larger sizes.

  In the interim, you could write 'correct' values using the 'dm i2c -a
50 0-7f'
command.  Here's an SPD dump from a 128MB SODIMM:

  0x80,0x08,0x04,0x0c,0x09,0x02,0x40,0x00,
  0x01,0x75,0x54,0x00,0x80,0x10,0x00,0x01,
  0x8f,0x04,0x06,0x01,0x01,0x00,0x0e,0xa0,
  0x60,0x00,0x00,0x14,0x0f,0x14,0x2d,0x10,
  0x15,0x08,0x15,0x08,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x97,
  0x7f,0x98,0x00,0x00,0x00,0x00,0x00,0x00,
  0x46,0x4d,0x34,0x20,0x36,0x34,0x53,0x30,
  0x36,0x34,0x43,0x33,0x2f,0x31,0x32,0x38,
  0x00,0x00,0x00,0x00,0x00,0x01,0x1e,0x1f



--
Gary Milliorn, Motorola
RISC Reference Platforms
Computing Platform Division

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

Re: 64Mbytes on Sandpoint-X3B

[Mark A. Greer]

Sergiy Kovtun wrote:

> Hello All,
> I try to connect all my 64 Meg memoty on
> Sandpoint-X3B,
> but received a crash( with 32M all OK).
> Source:
> SP-X3B + Altimus MPC7410
> HHL 2.0
> Any ideas??

IIRC, official hhl 2.0 didn't support the X3 but there was a patch that came
out at the same time that provided that support.  Are you using that patch?


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