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/
From: Jim Thompson <hidden> Date: 2002-05-31 15:01:39
Tom Rini writes:
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
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/
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
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/
From: Jim Thompson <hidden> Date: 2002-05-31 15:20:08
Tom Rini writes:
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
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/
On Fri, May 31, 2002 at 10:20:08AM -0500, Jim Thompson wrote:
Tom Rini writes:
quoted
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
quoted
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.
From: Mark A. Greer <hidden> Date: 2002-05-31 17:48:24
Tom Rini wrote:
On Fri, May 31, 2002 at 10:20:08AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
quoted
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)
quoted
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/
From: Mark A. Greer <hidden> Date: 2002-05-31 17:55:10
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/
On Fri, May 31, 2002 at 01:48:24PM -0400, Mark A. Greer wrote:
Tom Rini wrote:
quoted
On Fri, May 31, 2002 at 10:20:08AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
quoted
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)
quoted
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/
From: Mark A. Greer <hidden> Date: 2002-05-31 18:18:57
Tom Rini wrote:
quoted
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.
From: Mark A. Greer <hidden> Date: 2002-05-31 18:23:01
Tom Rini wrote:
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
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/
On Fri, May 31, 2002 at 02:18:57PM -0400, Mark A. Greer wrote:
Tom Rini wrote:
quoted
quoted
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/
From: Gary Milliorn <hidden> Date: 2002-05-31 20:35:53
"Mark A. Greer" wrote:
Tom Rini wrote:
quoted
On Fri, May 31, 2002 at 10:01:39AM -0500, Jim Thompson wrote:
quoted
Tom Rini writes:
quoted
On Thu, May 30, 2002 at 11:02:44PM -0700, Sergiy Kovtun wrote:
quoted
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/
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/
Yes, it works.
I worked with include/config_Sandpoint8245.h and cpu/74xx_7xx.
----- Original Message -----
From: "Sergiy Kovtun" <redacted>
To: <redacted>
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,