-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Bastos Fernandez Alexandre Sent: Wednesday, November 03, 2004 9:37 AM To: 'u-boot-users@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@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. ******************************************