Problem running Linux 2.6.11 on MPC8272ADS

Li Yang-r58472 LeoLi at freescale.com
Thu Mar 31 18:22:26 EST 2005


Good point.
There is also IMMR need to be passed from bootloader to kernel.  We can make more use of the u-boot bd_info mechanism.  But it binds ppc linux to u-boot boot loader.  I don't know if we should make it a porting convention.

Best Regards,
Leo

> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs at ebshome.net]
> Sent: Thursday, March 31, 2005 11:27 AM
> To: Li Yang-r58472
> Cc: Walter L. Wimer III; Gala Kumar K.-galak; Linux PPC Embedded list
> Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
> 
> On Thu, Mar 31, 2005 at 11:03:00AM +0800, Li Yang-r58472 wrote:
> > Well, it seems to be a historic problem.  Freescale BSP was
> > originally ported from u-boot-1.0.0 and linux-2.4.22.  So the BCSR
> > was freely chosen as 0xf8000000.  Later, we updated them to
> > u-boot-1.1.1 and linux-2.4.26, and make the BCSR consistent to older
> > version.  However the sourceforge u-boot-1.1.1 support for
> > MPC8272ADS
> > was committed by Arabella guys, they chose BCSR mapping to
> > 0xf4500000.  Kumar's MPC8272 support which is in 2.6.11 source was
> > developed using sourceforge u-boot-1.1.1 seemingly.
> >
> > This might brought up a question that if we need a convention or
> > something to define the recommended memory mapping for PowerPC BSPs.
> > As there are different groups of people around the world developing
> > BSPs for PowerPC platforms, and often the communication between them
> > is very limited.
> >
> > For now using kernel and u-boot released from the same vendor is recommended.
> >
> 
> There is trivial solution which will work regardless on which version
> of U-Boot and kernel you are using.
> 
> DO NOT hardcode such stuff in TWO DIFFERENT places, do this only in
> one, in this case it should be firmware (e.g. U-Boot).
> 
> In kernel just read BRx register for that chip select and use this
> address for accesses from the kernel. This is how I do on all my
> board ports.
> 
> No need to establish any artificial conventions on memory map, etc.
> 
> --
> Eugene



More information about the Linuxppc-embedded mailing list