RE: Problem running Linux 2.6.11 on MPC8272ADS

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@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:

quoted

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

On Thu, Mar 31, 2005 at 04:22:26PM +0800, Li Yang-r58472 wrote:

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.

Well, immr is _already_ part of bd_t passed from U-Boot! I was 
surprised that none of board ports (some of which are made for U-Boot 
only) use this. 

In 8248 based board port I'm working on right now, I already defined 
CPM_MAP_ADDR as follows:

#define CPM_MAP_ADDR            (((bd_t*)__res)->bi_immr_base)

--
Eugene

On Thu, 2005-03-31 at 02:22, Li Yang-r58472 wrote:

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.

Hi guys,

So, just for the record here, Kumar and I are moving the ppc32
line away from bd_t towards an OpenFirmware flattened device tree.
That data will still have a place for the IMMR to be passed.

Under another Subject:, I'll describe a brief outline of
The Plan So Far so people can take shots at it. :-)

Best Regards,
Leo

Thanks,
jdl