Re: [ECOS] Redboot & Powerpc: memory remap

Re: [ECOS] Redboot & Powerpc: memory remap

[ken king]

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

Yes, you can run out of RAM with a BDM. Here are some
hints to get you started;

1—you’ll need to change viper.S so that when it writes
/CS0 your memory map doesn’t vanish (assuming /CS0 is
ROM). First write BR0 as invalid, then set OR0 as
required, then write BR0 as valid.

For example (from viper.S) change....       	
	
	/* BOOT ROM */
        lwi	r3,0xFE000401	# 8-bit, GPCM
        lwi	r5,0xFF800774   # 7 wait states, up to 8MB
        stw	r3,BR0(r4)
        stw	r5,OR0(r4)
	
to....
	/* BOOT ROM */
        lwi	r3,0xFE000400	# 8-bit, GPCM--invalid!
        lwi	r5,0xFF800774   # 7 wait states, up to 8MB
        stw	r3,BR0(r4)
        stw	r5,OR0(r4)
        lwi	r3,0xFE000401	# 8-bit, GPCM--Valid
        stw	r3,BR0(r4)
	
2. Make sure the files mlt_powerpc_viper_ram.ldi,
mlt_powerpc_viper_ram.h, and mlt_powerpc_viper_ram.mlt
are correct for your memory map.


3. Create a .gdbinit file in the directory you run gdb
from and set your CS as required by your memory map.
For example (ONLY an example);

#BR0 ** changed to BR1 invalid
set *0xfff00100 =  0x00008000

#OR0
set *0xfff0104 = 0xffff0f50

#BR1** changed to BR1 set same as axiom bd BR0
#set *0x00000108 = 0x00000001
set *0xfff00108 = 0x00000081

#OR1
#set *0x10c = 0x00000100
set *0xfff0010c = 0xffe00100

#BR2
set *0xfff00110 = 0x00800081

#OR2
set *0xfff00114 = 0xfff00100


NOTE: the base address of these regs are set by the
reset config word -- so your addresses *may* be
different than the ones shown above. You will also
need to set these regs correctly for *your* board.

Hope this helps,
kk

--- Gary Thomas <gary@mlbassoc.com> wrote:
> On Sat, 2005-04-30 at 04:44 -0700,
> xinumike-rtos@yahoo.com wrote:
> > Powerpc question:
> > Ok, I understand chip select 0 is mapped to 0
> > upon reset and then it is remapped to something
> > like 0xfe000000. I understand that SDRAM will
> > be remapped to 0.   Where does this remapping 
> > take place (what file or files?)?
> > 
> > How does redboot do this remapping?  Does it
> execute
> > out of dual port ram for a while?
> > 
> > I know my answers are dig in the code, but if
> somebody
> > could give me a headstart what files to pay
> > particular attention too, I would appreciate it.
> > Is there any documentation that talks about
> > the boot process?
> 
> This happens in the machine setup code which on
> PowerPC systems
> is called 'hal_hardware_init'.  For an example, look
> at the
> Viper startup in:
>   .../hal/powerpc/viper/current/src/viper.S
> 
> When the processor is reset, *ALL* accesses go
> through CS0
> which implicitly maps *EVERYTHING*.  Thus, for the
> first few
> instructions, the only thing that can be accessed is
> the FLASH
> and the CPU control registers known as IMM in the
> code.  The
> first thing this code does is to tell the IMM how to
> map FLASH
> at 0xFE000000 via CS0 and SDRAM at 0x00000000 via
> CS1.  It then
> programs the UPM (a microcoded SDRAM controller). 
> Once this is
> done, FLASH and RAM can be accessed and the rest of
> the system
> can be initialized.
> 
> The details of how all of this works are in the
> MPC860 users
> manual (PDF available directly from
> FreeScale/Motorola)
> 
> Note: this is all very hardware specific.  Machine
> initialization
> is different on MPC8xx from MPC8xxx or ARM or 80x86
> or ...
> You have to know your platform :-)
> 
> -- 
>
------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
>
------------------------------------------------------------
> 
> 
> -- 
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
> 
> 



		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot & Powerpc: memory remap

[xinumike-rtos]

Gary, 

Thanks a lot for your response.  I am still a tiny
bit confused, and the source code is on my laptop in 
the office, so I hope you don't mind one more answer.

It would seem to me, that as soon as the code remaps
CS0 from 0 to 0xff000000, the program counter would
be messed up and we would be off in the weeds.
Obviously that is not what happens...so how does 
that work?

Also, it is possible to download through a BDM
and run right from RAM to debug, correct?

Thanks a lot for your help.  I really appreciate it.

-Mike

--- Gary Thomas <gary@mlbassoc.com> wrote:
> On Sat, 2005-04-30 at 04:44 -0700,
> xinumike-rtos@yahoo.com wrote:
> > Powerpc question:
> > Ok, I understand chip select 0 is mapped to 0
> > upon reset and then it is remapped to something
> > like 0xfe000000. I understand that SDRAM will
> > be remapped to 0.   Where does this remapping 
> > take place (what file or files?)?
> > 
> > How does redboot do this remapping?  Does it
> execute
> > out of dual port ram for a while?
> > 
> > I know my answers are dig in the code, but if
> somebody
> > could give me a headstart what files to pay
> > particular attention too, I would appreciate it.
> > Is there any documentation that talks about
> > the boot process?
> 
> This happens in the machine setup code which on
> PowerPC systems
> is called 'hal_hardware_init'.  For an example, look
> at the
> Viper startup in:
>   .../hal/powerpc/viper/current/src/viper.S
> 
> When the processor is reset, *ALL* accesses go
> through CS0
> which implicitly maps *EVERYTHING*.  Thus, for the
> first few
> instructions, the only thing that can be accessed is
> the FLASH
> and the CPU control registers known as IMM in the
> code.  The
> first thing this code does is to tell the IMM how to
> map FLASH
> at 0xFE000000 via CS0 and SDRAM at 0x00000000 via
> CS1.  It then
> programs the UPM (a microcoded SDRAM controller). 
> Once this is
> done, FLASH and RAM can be accessed and the rest of
> the system
> can be initialized.
> 
> The details of how all of this works are in the
> MPC860 users
> manual (PDF available directly from
> FreeScale/Motorola)
> 
> Note: this is all very hardware specific.  Machine
> initialization
> is different on MPC8xx from MPC8xxx or ARM or 80x86
> or ...
> You have to know your platform :-)
> 
> -- 
>
------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
>
------------------------------------------------------------
> 
> 
> -- 
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
> 
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot & Powerpc: memory remap

[Gary Thomas]

On Sat, 2005-04-30 at 04:44 -0700, xinumike-rtos@yahoo.com wrote:
> Powerpc question:
> Ok, I understand chip select 0 is mapped to 0
> upon reset and then it is remapped to something
> like 0xfe000000. I understand that SDRAM will
> be remapped to 0.   Where does this remapping 
> take place (what file or files?)?
> 
> How does redboot do this remapping?  Does it execute
> out of dual port ram for a while?
> 
> I know my answers are dig in the code, but if somebody
> could give me a headstart what files to pay
> particular attention too, I would appreciate it.
> Is there any documentation that talks about
> the boot process?

This happens in the machine setup code which on PowerPC systems
is called 'hal_hardware_init'.  For an example, look at the
Viper startup in:
  .../hal/powerpc/viper/current/src/viper.S

When the processor is reset, *ALL* accesses go through CS0
which implicitly maps *EVERYTHING*.  Thus, for the first few
instructions, the only thing that can be accessed is the FLASH
and the CPU control registers known as IMM in the code.  The
first thing this code does is to tell the IMM how to map FLASH
at 0xFE000000 via CS0 and SDRAM at 0x00000000 via CS1.  It then
programs the UPM (a microcoded SDRAM controller).  Once this is
done, FLASH and RAM can be accessed and the rest of the system
can be initialized.

The details of how all of this works are in the MPC860 users
manual (PDF available directly from FreeScale/Motorola)

Note: this is all very hardware specific.  Machine initialization
is different on MPC8xx from MPC8xxx or ARM or 80x86 or ...
You have to know your platform :-)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Redboot & Powerpc: memory remap

[xinumike-rtos]

Powerpc question:
Ok, I understand chip select 0 is mapped to 0
upon reset and then it is remapped to something
like 0xfe000000. I understand that SDRAM will
be remapped to 0.   Where does this remapping 
take place (what file or files?)?

How does redboot do this remapping?  Does it execute
out of dual port ram for a while?

I know my answers are dig in the code, but if somebody
could give me a headstart what files to pay
particular attention too, I would appreciate it.
Is there any documentation that talks about
the boot process?

Thanks,
 Mike

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss