Relocating PPCBoot into SRAM

Relocating PPCBoot into SRAM

[Arun Dharankar]

Greetings!

- On MPC75x and MPC7410 boards with MPC8260 in companion
  mode, SRAM on 1M and 2M respectively are available.

- Is it possible to relocate PPCBoot to this SRAM mapped
  as private memory? Note that, this is a second relocation;
  the first would already have occured when it is relocated
  from Flash to SDRAM.

- And if this possible, a re-relocation from SRAM back to
  SDRAM?


If this is possible, what needs to be done? The idea I
would like to explore is to do a full memory test (walking
bit, aligned/non-aligned access, refresh, alternating
pattern, random pattern test - basically extensive testing)
without executing PPCBoot in SDRAM.

And that these tests are part of PPCBoot commands (or
applications, perhaps).



Best regards,
-Arun.


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

Re: Relocating PPCBoot into SRAM

[Wolfgang Denk]

In message <200302161254.35753.ADharankar@ATTBI.Com> you wrote:
>
> - On MPC75x and MPC7410 boards with MPC8260 in companion
>   mode, SRAM on 1M and 2M respectively are available.
>
> - Is it possible to relocate PPCBoot to this SRAM mapped
>   as private memory? Note that, this is a second relocation;
>   the first would already have occured when it is relocated
>   from Flash to SDRAM.

This makes little sense to me. If you want to run  U-Boot  /  PPCBoot
from SRAM, then relocate it to that memory in the first place.

> - And if this possible, a re-relocation from SRAM back to
>   SDRAM?

Well, _everything_ is possible. But it is not wise  to  do  (or  try)
everything.
>
> If this is possible, what needs to be done? The idea I
> would like to explore is to do a full memory test (walking
> bit, aligned/non-aligned access, refresh, alternating
> pattern, random pattern test - basically extensive testing)
> without executing PPCBoot in SDRAM.

You don't have to do is that complicated. There are many easier ways,
for ewxample: You can implement your memory  test  (which  should  be
non-destructive) as a U-Boot standalone application which gets loaded
into and started from SRAM. No nood to relocate U-Boot at all.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
See us @ Embedded World, Nuremberg, Feb 18-20, Hall 12.0 Booth 12-442

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

Re: Relocating PPCBoot into SRAM

[Wolfgang Denk]

In message <200302161415.19790.ADharankar@ATTBI.Com> you wrote:
> Hello!  Thanks for the nice reply!

You're welcome.

> To test the region of SDRAM where PPCBoot/U-Boot resides, how could
> a non-destructive test be implemented? Perhaps, would one way would be
> to do these test for that region of PPCBoot/U-Boot before it is
> relocated to SDRAM?

This is a good idea, especially since you also have to deal with  the
exception vectors...

> Some of the x86 PC BIOSs/Bootloaders/Monitors seem to be able to do
> a full/destructive memory test without a reboot. That is what seems
> to be appealing to for PPCBoot/U-Boot.

Did you check how U-Boot's POST routines  (especially  post/memory.c)
work?

Don't re-invent the wheel.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
See us @ Embedded World, Nuremberg, Feb 18-20, Hall 12.0 Booth 12-442

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

RE: Relocating PPCBoot into SRAM

[Kerl, John]

> If PPCBoot/U-Boot were to be relocated into SRAM in the first place,
> is there a potential for any problem (the CPM SDMA? probably not -
> the buffer descriptors are in DPRAM...)?

I've run software out of both SRAM & SDRAM; the CPM doesn't
seem to care.  (For some simple devices (e.g. UARTs) the
BDs might have to be in DPRAM; for others (e.g. SCC, FEC)
the BDs can be in external memory -- SRAM or SDRAM.  & I
think that for all CPM devices I've seen, the I/O buffers
(what the BDs point to) can be in any memory.  You have to
make sure you tell the CPM the physical, not virtual addresses,
and also make sure the CPU doesn't have those areas cached.
But these issues apply equally to SDRAM, SRAM and DPRAM.)

> To test the region of SDRAM where PPCBoot/U-Boot resides, how could
> a non-destructive test be implemented? Perhaps, would one way would be
>  do these test for that region of PPCBoot/U-Boot before it is
> located to SDRAM?
>
> Some of the x86 PC BIOSs/Bootloaders/Monitors seem to be able to do
> full/destructive memory test without a reboot. That is what seems
> to be appealing to for PPCBoot/U-Boot.

1.	BIOSes, at startup, seem to have code in about 1K of RAM, and
	do a minimal test of the *rest*.  (I think, just 1-pass
	address uniqueness.)  This is a weak test.

2.	If you run out of one memory (e.g. SRAM) you can test all of
	another memory.  This is what we do at Avnet Design Services
	-- run out of SRAM to test SDRAM.

	If you don't have an SRAM, then you might be able to fit a
	very compact memory tester entirely into DPRAM.

	(On one previous project, not with a PPC, I ran an SDRAM
	test while taking instructions from flash & with stack/data
	in a small on-chip RAM.  The memory test passed.  Then I
	ran the same test code, but with instructions taken from
	SRAM.  The test now failed because I was hitting the memory
	more quickly, & found a timing problem.  Caveat emptor.)

3.	memtest86 runs out of main memory (whatever is on your PC
	-- SDRAM, DDRAM, etc.) and does shared-library/ELF tricks
	to run out of one position to test some memory, then copy
	itself to another location & then test the memory it had
	been running out of.  Nice trick, if you want to pull it off,
	but it does take a fair amount of setup & personally I think
	option 2 above is preferable when possible.


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

Re: Relocating PPCBoot into SRAM

[Arun Dharankar]

John, this is very encouraging! Thanks!

There could be a way of "relocating" PPCBoot/U-Boot using
SRAM configured as private memory (at least on the boards I
have access to (7410/750 with MPC8260 in companion mode).
Is what you did too?

  - To begin with, SRAM is configured (using L2PM, ofcourse)
    outside the SDRAM range (possibly where no CS/BR is
    mapping to).
  - PPCBoot/U-Boot text, data, stack copied over into SRAM
  - Then map the SRAM in such a way that it overlaps the SDRAM
    range (text, data and stack in SRAM are mapped at the
    same addresses as when in the SDRAM).
  - Next map, the SDRAM into another address region changing
    the BR for SDRAM (making sure no other CS/BR uses that
    range)

With this much, PPCBoot/U-Boot is executing out of SRAM, and
SDRAM is available for a complete/destructive test. Once the
test is done, the reverse could be done.


The CPM cannot "see" the SRAM, so FCC and likes (with buffers
in SDRAM) would not work. In any case, this does not matter
since only the SDRAM is being tested, and nothing else should
go on at during this time.


A variation of this could be to implement this test as a PPCBoot/
U-Boot application (linked/loaded such that it also lies in the
SRAM).


Quite obviously, since SRAM may not be available in all boards,
this may not be a generic way of testing SDRAM.


Any flaws with this scheme?


Wolfgang pointed out potential issue with the exception vectors.
Since this relocation is done only during the period of time
when the SDRAM tests are being executed, what could be the risks?


Also, the new memory tests in U-Boot are cool! I dont have to
reinvent them (really!). Thanks Wolfgang!


Best regards,
-Arun.


On Tuesday 18 February 2003 06:27 pm, Kerl, John wrote:
> > If PPCBoot/U-Boot were to be relocated into SRAM in the first place,
> > is there a potential for any problem (the CPM SDMA? probably not -
> > the buffer descriptors are in DPRAM...)?
>
> I've run software out of both SRAM & SDRAM; the CPM doesn't
> seem to care.  (For some simple devices (e.g. UARTs) the
> BDs might have to be in DPRAM; for others (e.g. SCC, FEC)
> the BDs can be in external memory -- SRAM or SDRAM.  & I
> think that for all CPM devices I've seen, the I/O buffers
> (what the BDs point to) can be in any memory.  You have to
> make sure you tell the CPM the physical, not virtual addresses,
> and also make sure the CPU doesn't have those areas cached.
> But these issues apply equally to SDRAM, SRAM and DPRAM.)
>
> > To test the region of SDRAM where PPCBoot/U-Boot resides, how could
> > a non-destructive test be implemented? Perhaps, would one way would be
> >  do these test for that region of PPCBoot/U-Boot before it is
> > located to SDRAM?
> >
> > Some of the x86 PC BIOSs/Bootloaders/Monitors seem to be able to do
> > full/destructive memory test without a reboot. That is what seems
> > to be appealing to for PPCBoot/U-Boot.
>
> 1.	BIOSes, at startup, seem to have code in about 1K of RAM, and
> 	do a minimal test of the *rest*.  (I think, just 1-pass
> 	address uniqueness.)  This is a weak test.
>
> 2.	If you run out of one memory (e.g. SRAM) you can test all of
> 	another memory.  This is what we do at Avnet Design Services
> 	-- run out of SRAM to test SDRAM.
>
> 	If you don't have an SRAM, then you might be able to fit a
> 	very compact memory tester entirely into DPRAM.
>
> 	(On one previous project, not with a PPC, I ran an SDRAM
> 	test while taking instructions from flash & with stack/data
> 	in a small on-chip RAM.  The memory test passed.  Then I
> 	ran the same test code, but with instructions taken from
> 	SRAM.  The test now failed because I was hitting the memory
> 	more quickly, & found a timing problem.  Caveat emptor.)
>
> 3.	memtest86 runs out of main memory (whatever is on your PC
> 	-- SDRAM, DDRAM, etc.) and does shared-library/ELF tricks
> 	to run out of one position to test some memory, then copy
> 	itself to another location & then test the memory it had
> 	been running out of.  Nice trick, if you want to pull it off,
> 	but it does take a fair amount of setup & personally I think
> 	option 2 above is preferable when possible.
>
>


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