[DNX#2006040142000124] [U-Boot-Users] Re: MPC8272ADS Hangs with gcc 4.0.0 [...]

[DENX Support System]

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000124] was created:

<snip>
> Thank you Wolfgang
> 
> Your advice was very useful. I got the board working! I would want to
> submit a patch, but I'm not sure about what my modification can do in
> the whole code. I suspect that there are other part(s) of the code
> that suffer with new GCC 4 optimizations.
> 
> I started debugging with BDI2000. After a lot of steps, I found where
> the board hanged. In fact, the processor resets in line 33 of
> cpu/mpc8260.c, function m8260_cpm_reset()
> 
> line 33 : gd->dp_alloc_base = CPM_DATAONLY_BASE;
> 
> The gd variable was appointing to a wrong address. gd is a "register
> volatile", as it is defined in include/asm-ppc/global_data.h:
> 
> #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm
> ("r29")
> 
> Inspecting assembler generated code, I've found that before this
> funcion, r29 should be initiated with the correct value. This should
> be done in function cpu_init_f(), but no assembler code was generated
> from the line that initialized gd:
> 
> void cpu_init_f (volatile immap_t * immr)
> {
> 	DECLARE_GLOBAL_DATA_PTR;
> 	//register volatile gd_t *gd asm ("r29");
> 	
> #if !defined(CONFIG_COGENT)		/* done in start.S for the cogent */
> 	uint sccr;
> #endif
> 	volatile memctl8260_t *memctl = &immr->im_memctl;
> 	extern void m8260_cpm_reset (void);
> 
> 	/* Pointer is writable since we allocated a register for it */
> 	gd = (gd_t *) (CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET);
> 
> 	/* Clear initial global data */
> 	memset ((void *) gd, 0, sizeof (gd_t));
> 
> ....
> 
> So, I searched the web and found someone that was working with u-boot
> and posted a possible GCC "optimization bug":
> 
> http://gcc.gnu.org/ml/gcc-bugs/2005-08/msg01984.html
> 
> And, in the end, a solution was given:
> 
> http://gcc.gnu.org/ml/gcc-bugs/2005-08/msg02003.html
> 
> This way, I modified the definition of DECLARE_GLOBAL_DATA_PTR to:
> 
> #define DECLARE_GLOBAL_DATA_PTR    register gd_t*volatile gd asm
> ("r29");
> 
> Now I compile the code and the board runs! But, for my surprise, a lot
> of warnings are produced, like this:
> 
> cpu_init.c: In function 'cpu_init_f':
> cpu_init.c:99: warning: volatile register variables don't work as you
> might wish
> 
> I know my new declaration can be wrong. But the old one seems to be
> wrong too.
> 
> Any idea?
> 
> Best Regards,
> Addison Baldwin
> 
> On 2/2/06, Ron Kellam <ronkbox-news at yahoo.com> wrote:
> > >If anyone had this problem, or if anyone have such a configuration
> > >working (GCC 4 and U-Boot 1.1.4 with this board), any help will be
> > >very appreciated.
> >
> > I have a custom board very similar to the MPC8272ADS, but without the
> > BCSR FPGA.
> >
> > My board also hangs with u-boot 1.1.4 compiled with ELDK4.0's gcc 4,
> > so the problem is not just the BCSR accesses.
> >
> > For now I'm sticking with my ELDK3.1.1 compiled u-boot, as I don't
> > have time to debug u-boot when I have a working one.
> >
> > Could you please post your findings if you get to the bottom of it.
> >
> > Regards,
> > Ron Kellam
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > U-Boot-Users mailing list
</snip>

Your U-Boot support team