[U-Boot-Users] DBGFLASGS in MPC8272ADS

VanBaren, Gerald (AGRE) Gerald.VanBaren at smiths-aerospace.com
Wed Nov 3 16:14:51 CET 2004


> -----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.
******************************************




More information about the U-Boot mailing list