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