[U-Boot-Users] TEXT_BASE question

[U-Boot-Users] TEXT_BASE question

[Frank Young]

Hi,

I am trying to install u-boot on my walnut board with PPC405. In file 
board/walnut405/config.mk, TEXT_BASE is defined as FFFE0000. Does that mean 
the u-boot.bin has to start from FFFE0000?

My problem is that on my board the address space from FFF80000 to FFFFFFFF 
is reserved for a special purpose, so I can't put the u-boot.bin at 
FFFE0000. But if I change the TEXT_BASE to another one, for example 
FFF00000, then the u-boot.bin generated by the compiler is FFFFFFFF - 
FFF00000 = 1MB. It means I still can't put the u-boot.bin to FFF00000 
because it will overwrite the reserved address space anyway. I understand 
that u-boot is trying to fill the gap between TEXT_BASE and the end of the 
flash. So my question is:

1. If I use TEXT_BASE = FFFE0000 and simply put the u-boot.bin generated to 
FFF00000, will it mess up the addressing in the u-boot?

2. If the answer for 1 is yes, how can I move up the end of flash to 
FFF80000 so that the u-boot.bin will fill from FFF00000 to FFF80000 instead 
of from FFF00000 to FFFFFFFF?


Thanks,
Frank

_________________________________________________________________
Make the most of your family vacation with tips from the MSN Family Travel 
Guide! http://dollar.msn.com

[U-Boot-Users] TEXT_BASE question

[Wolfgang Denk]

In message <BAY2-F23dBdsnvUFcxT00007dc2@hotmail.com> you wrote:
> 
> My problem is that on my board the address space from FFF80000 to FFFFFFFF 
> is reserved for a special purpose, so I can't put the u-boot.bin at 

This is not possible. For example, the IBM  4xx  processor  hat  it's
reset vector at 0xFFFFFFFC, so the last 4 bytes in your address space
cannot  be  "reserved  for  a  special purpose" (except this "special
purpose" is another boot loader).

> 1. If I use TEXT_BASE = FFFE0000 and simply put the u-boot.bin generated to 
> FFF00000, will it mess up the addressing in the u-boot?

Yes,. of course. Why do you think you  have  to  ask  this  question?
Isn't this obvious?

> 2. If the answer for 1 is yes, how can I move up the end of flash to 
> FFF80000 so that the u-boot.bin will fill from FFF00000 to FFF80000 instead 
> of from FFF00000 to FFFFFFFF?

You cannot. At least a branch instruction must be paced at the  reset
vector,  which  is  0xFFFFFFFC,  which  is the end of your "reserved"
area.


Please redefine your requirements.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Men will always be men -- no matter where they are.
	-- Harry Mudd, "Mudd's Women", stardate 1329.8

[U-Boot-Users] TEXT_BASE question

[robert lazarski]

Hi all,

I see that many boards use, and that TEXT_BASE is often defined in
config.mk . In my 85xx case, I have:

TEXT_BASE = 0xfff80000

However, some of my registers are using TEXT_BASE + DATA that don't
seem right. In the bdi I get:

ATUM>rd ivor15
ivor15         : 0x00000f00  3840

That seems out of range of my 4K stack before relocation, could that
be a problem or am I simply reading this wrong?

Thanks,
Robert

[U-Boot-Users] TEXT_BASE question

[Swarthout Edward L-SWARTHOU]

From: robert lazarski
> 
> ATUM>rd ivor15
> ivor15         : 0x00000f00  3840
> 
> That seems out of range of my 4K stack before relocation, could that
> be a problem or am I simply reading this wrong?

Check ivpr, they work together.

It is only used for the debugger - so it only has to point to a 
fetchable memory location so the cpu can halt under debugger control.
 
-ELS

[U-Boot-Users] TEXT_BASE question

[robert lazarski]

On 9/27/07, Swarthout Edward L-SWARTHOU <ed.swarthout@freescale.com> wrote:
> From: robert lazarski
> >
> > ATUM>rd ivor15
> > ivor15         : 0x00000f00  3840
> >
> > That seems out of range of my 4K stack before relocation, could that
> > be a problem or am I simply reading this wrong?
>
> Check ivpr, they work together.
>
> It is only used for the debugger - so it only has to point to a
> fetchable memory location so the cpu can halt under debugger control.
>
> -ELS
>
>

Indeed, one of my problems is that the bdi is giving me a 'core is
stopped' while debugging - a clear indication of a problem reading
ivor15. My understanding is that on 85xx, special 63 is ivpr and
ivor15 is 415. When I set a breakpoint early in the u-boot code, yet
after those registers have been initialized and before my TLB's crash,
I get:

ATUM>rdspr 415
SPR  415 : 0x00000f00         3840
ATUM>rdspr 63
SPR   63 : 0xfff80000  -    524288

0xfff80000 + f00 == 0xfff80f00 . In the bdi config I have tried:

WSPR    63          0xfff80000
WSPR    415         0x00000f00

Yet I still get 'core is stopped' while debugging. I may be lacking a
L2 entry of some sort. L2CAM shows:

ATUM>l2cam 0 0xf
IDX  PID      EPN  SIZE V TS           RPN U0-U3 WIMGE UUUSSS
  0 : 00 fffff000   4KB V  0 -> 0_fffff000  0000 -I--- ---RWX
  1 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  2 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  3 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  4 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  5 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  6 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  7 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  8 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
  9 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
 10 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
 11 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
 12 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
 13 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
 14 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------
 15 : 00 00000000   1KB -  0 -> 0_00000000  0000 ----- ------

If I get debugging working it may be a critical piece in finding my
problems. Any ideas on what is preventing me from debugging? Thanks!
Robert