[U-Boot-Users] DBGFLASGS in MPC8272ADS

[U-Boot-Users] DBGFLASGS in MPC8272ADS

[Bastos Fernandez Alexandre]

Hi,

After running U-boot-1.1.1 for some months, I am now trying the last CVS
version of Uboot (1.1.2) in my MPC8272ADS board. Now, my available
"infrastructure" has also grown, as "daddy" has bought a BDI2000 for me. :-)

I was trying to gain knowledge about the relocation address of Uboot into
SDRAM, so i have tried adding the -DDEBUG to DBGFLAGS in config.mk to get
all the debug("xxx") messages.

Unfortunately, when I do this, uboot (or the board itself) keeps rebooting
all the time, without showing anything through the console.

Using my BDI2000 I can see, in RUN mode, that the board is getting a
periodic reset. I have tried to debug the init process in HALT mode, but
here I have another problem ... when I reach this instruction form start.S 

boot_cold:
#if defined(CONFIG_MPC8260ADS)
	lis	r3, CFG_DEFAULT_IMMR at h
	nop
=>	lwz	r4, 0(r3)
	...

the board resets itself. This arrives both, when I use the image with
-DDEBUG flag, and when I use the image without this flag (which runs OK in
the board).

Any idea about those problems?

Thanks

Alex

[U-Boot-Users] DBGFLASGS in MPC8272ADS

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf
> Of Bastos Fernandez Alexandre
> Sent: Wednesday, November 03, 2004 9:37 AM
> To: 'u-boot-users at lists.sourceforge.net'
> Subject: [U-Boot-Users] DBGFLASGS in MPC8272ADS
>
> Hi,
>
> After running U-boot-1.1.1 for some months, I am now trying
> the last CVS version of Uboot (1.1.2) in my MPC8272ADS board.
> Now, my available "infrastructure" has also grown, as "daddy"
> has bought a BDI2000 for me. :-)
>
> I was trying to gain knowledge about the relocation address
> of Uboot into SDRAM, so i have tried adding the -DDEBUG to
> DBGFLAGS in config.mk to get all the debug("xxx") messages.
>
> Unfortunately, when I do this, uboot (or the board itself)
> keeps rebooting all the time, without showing anything
> through the console.
>
> Using my BDI2000 I can see, in RUN mode, that the board is
> getting a periodic reset. I have tried to debug the init
> process in HALT mode, but here I have another problem ...
> when I reach this instruction form start.S
>
> boot_cold:
> #if defined(CONFIG_MPC8260ADS)
> 	lis	r3, CFG_DEFAULT_IMMR at h
> 	nop
> =>	lwz	r4, 0(r3)
> 	...
>
> the board resets itself. This arrives both, when I use the
> image with -DDEBUG flag, and when I use the image without
> this flag (which runs OK in the board).
>
> Any idea about those problems?
>
> Thanks
>
> Alex

This looks like you are getting bitten by the horrible HRCW IMMR
configuration choice that Mot/Freescale/EST/WindRiver (I don't know who
was first :-) made.

If you boot using the BCSR to source the HRCW (see the 826x User's
Manual on the HRCW, probably Chapter 5), Mot sets the initial IMMR
memory area to be at 0x0f000000.  This is incompatible with linux, so
the u-boot initialization (the code you've highlighted) writes to the
IMMR register to change it to 0xf0000000.

Your BDI config file probably does this as well.

The problem is, the BDI and the actual code get confused about where the
IMMR memory region is and one (or both :-O) of them accesses the wrong
memory region, causing a bus fault which results in the reset you see.

My guess is your BDI config file remaps the IMMR and, when you step
through the code, the code's writing of the IMMR screws up.  I don't
know how clever the BDI is in terms of examining the instructions it is
executing; it is possible that it catches the IMMR write and tries to Do
The Right Thing[tm] when it sees the IMMR write attempt but it screws
up.

Your best bet is to use a flash-based HRCW and set the IMMR in the
right(!!!) location out of reset.  (I also would recommend switching to
"boot low", in which case you can have one u-boot copy booting high via
the BCSR and one copy booting low via the flash HRCW.  By doing this,
you can test using the flash HRCW and, when you screw up, you can
recover by booting high and loading a fixed u-boot in the low spot).  I
have this change configured in my local (at home) copy and intend to
submit it to Wolfgang Real Soon Now[tm].

While we are on the subject of patching this, my only reason for not
submitting the patch yet is because I want to configure the link control
file so that it automatically knows to link at 0xfff00000 for the "boot
high" option and 0xfe800000 for the "boot low" option.  I have that
hard-coded presently and have not had time to figure out how to do it
using a configuration selection.  Hints would be welcome :-).

gvb


******************************************
The following messages are brought to you by the Lawyers' League of
IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] DBGFLASGS in MPC8272ADS

[alebas at televes.com]

Hi Gerald,

Citando "VanBaren, Gerald (AGRE)" <Gerald.VanBaren@smiths-aerospace.com>:

> This looks like you are getting bitten by the horrible HRCW IMMR
> configuration choice that Mot/Freescale/EST/WindRiver (I don't know who
> was first :-) made.
>
> If you boot using the BCSR to source the HRCW (see the 826x User's
> Manual on the HRCW, probably Chapter 5), Mot sets the initial IMMR
> memory area to be at 0x0f000000.  This is incompatible with linux, so
> the u-boot initialization (the code you've highlighted) writes to the
> IMMR register to change it to 0xf0000000.
>
> Your BDI config file probably does this as well.
>
> The problem is, the BDI and the actual code get confused about where the
> IMMR memory region is and one (or both :-O) of them accesses the wrong
> memory region, causing a bus fault which results in the reset you see.
>
> My guess is your BDI config file remaps the IMMR and, when you step
> through the code, the code's writing of the IMMR screws up.  I don't
> know how clever the BDI is in terms of examining the instructions it is
> executing; it is possible that it catches the IMMR write and tries to Do
> The Right Thing[tm] when it sees the IMMR write attempt but it screws
> up.


I think you have guessed ok. I have checked my config file, and it  sets the
IMMR to 0x04700000, which is the value it has in the user manual for the board
(i got the config file from Abatron)

>
> Your best bet is to use a flash-based HRCW and set the IMMR in the
> right(!!!) location out of reset.  (I also would recommend switching to
> "boot low", in which case you can have one u-boot copy booting high via
> the BCSR and one copy booting low via the flash HRCW.  By doing this,
> you can test using the flash HRCW and, when you screw up, you can
> recover by booting high and loading a fixed u-boot in the low spot).  I
> have this change configured in my local (at home) copy and intend to
> submit it to Wolfgang Real Soon Now[tm].


OK, but as a fast test before doing that, if I remove the IMMR lines from my
config file, then there wouldn't be any inconsistency, so I would be able to
debug this lines of uboot. Am I wrong?.

And, why does it works when I do the RESET RUN? Should I guess than in this case
the BDI2000 restarts the board without doing any special initialization?

>
> While we are on the subject of patching this, my only reason for not
> submitting the patch yet is because I want to configure the link control
> file so that it automatically knows to link at 0xfff00000 for the "boot
> high" option and 0xfe800000 for the "boot low" option.  I have that
> hard-coded presently and have not had time to figure out how to do it
> using a configuration selection.  Hints would be welcome :-).
>
> gvb
>

However, all this stuff doesn't explain or solves the other problem ... why the
-DDEBUG flag doesn't works?

Thanks for your reply,

Alex

[U-Boot-Users] DBGFLASGS in MPC8272ADS

[Wolfgang Denk]

In message <1099582987.418a4e0b80676@webmail.televes.com:443> you wrote:
> 
...
> However, all this stuff doesn't explain or solves the other problem ... why the
> -DDEBUG flag doesn't works?

Most probably because someone was clever and added (but never tested)
debug statements to code that is running  before  console  output  is
available.  If  you  try  to use printf() too early (i. e. before the
serial port has been initialized and  assigned)  you  will  run  into
trouble.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
                                             - Terry Pratchett, _Eric_