Problem porting 2.4.17 linux to MPC8260ADS

Problem porting 2.4.17 linux to MPC8260ADS

[Kamalesh B]

Hello,

Iam porting Linux 2.4.17 on MPC8260ADS. I had already working
Linux-2.4.1 version on MPC8260ADS board.

I have patched all the board specific changes to 2.4.17 and compiled.
When i loaded the image on board using PPCBOOT and run it, it hangs in
function "MMU_init_hw" (arch/ppc/mm/ppc_mmu.c) which is called from
MMU_init (arch/ppc/mm/init.c). And MMU_init is called from "_start_here"
subroutine in head.S file.

I had rather taken an tedious process of identifying the problem by
glowing LEDs present on the board. I have identify the location of the
problem.

Problem:
In "MMU_init_hw" function, it checks for this condition
"cur_cpu_spec[0]->cpu_features & CPU_FTR_HPTE_TABLE" and panics by
blinking leds in specific pattern after accessing the structure.

--- Code begins ---
 if ((cur_cpu_spec[0]->cpu_features & CPU_FTR_HPTE_TABLE) == 0) {
  /*
   * Put a blr (procedure return) instruction at the
   * start of hash_page, since we can still get DSI
   * exceptions on a 603.
   */
  hash_page[0] = 0x4e800020;
  flush_icache_range((unsigned long) &hash_page[0],
       (unsigned long) &hash_page[1]);
  return;
 }
--- Code ends ---

"cur_cpu_spec" is a array of pointer to cpu_spec structure
(include/asm-ppc/cputable.h) containing CPU related informations. I
understand that this is something to do with multiple processors system.
I checked the value of cur_cpu_spec[0] pointer. It was zero. At this
time, MMU would be ON with SDRAM located at 0xc0000000 (Logical
address). So when processor access this sructure which is pointing to 0
(outside physical memory boundary), it throws machine check exception
and calls panic function to display leds in specific pattern. This is
where iam stuck.

I also tried commenting this line as this was not there in 2.4.1
version. Here control went till this point in "head.S" code

--- Code start ---
/*
 * Go back to running unmapped so we can load up new values
 * for SDR1 (hash table pointer) and the segment registers
 * and change to using our exception vectors.
 */
 lis r4,2f@h
 ori r4,r4,2f@l
 tophys(r4,r4)
 li r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
 FIX_SRR1(r3,r5)
 mtspr SRR0,r4
 mtspr SRR1,r3
 SYNC
 RFI
/* Load up the kernel context */
2:

--- Code ends ---

After RFI instruction executed, it stops or hangs without any
indication. Expected result was control should jumps to label "2:" and
then branch to "load_up_mmu" function and "start_kernel" function.

I suspect cpu setup problem and may be MMU also.

Any help will be appreciated,
thanks in advance,
with rgds,
kamal

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem porting 2.4.17 linux to MPC8260ADS

[Dan Malek]

Kamalesh B wrote:

> Iam porting Linux 2.4.17 on MPC8260ADS. I had already working
> Linux-2.4.1 version on MPC8260ADS board.

There should be very minimal changes required to support the 8260ADS,
just a few memory mapping initializations.  Everything else is generic
to all of the other 8260 boards that are supported.

> I had rather taken an tedious process of identifying the problem by
> glowing LEDs present on the board. I have identify the location of the
> problem.

Well....think about this for a moment......In order to flash the LEDs
you need access to the board control register.  Once you initialize
the MMU for Linux, these mappings are gone and you need to set them
up again within the Linux memory map.  There are several memory map
transistions during the start up of Linux.  Very early in the start
up code it enables the MMU and only maps a small portion of real
memory.  You won't be able to access LEDs after this point.

> I checked the value of cur_cpu_spec[0] pointer. It was zero.

How did you check this?  The processor is running with caches enabled,
this pointer is initialized during the start up.  If you dumped out
main memory after the crash, I doubt it was written out of the cache.

> I also tried commenting this line as this was not there in 2.4.1
> version. Here control went till this point in "head.S" code

Not a good idea.  There are subtle changes happening all of the time,
and the difference between 2.4.1 and 2.4.17 is quite a bit.

I suspect your access to the LEDs is crashing due to memory mapping
changes, and taking you down the wrong path.

As I said, there should be very minimal board specific changes
required.  A header file in arch/ppc/platforms, some updates to the
bootloader, ensure the IMMR is set to 0xf0000000 before calling the
kernel and you should have a console prompt.  If you want to access
other board control registers, they will have to be ioremapped()
somewhere in the kernel before you use them.



	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem porting 2.4.17 linux to MPC8260ADS

[Kamalesh B]

hello,

I have done all the memory mapping stuffs according to the board. Please see
my inputs to your answers.

Dan Malek wrote:

> Kamalesh B wrote:
>
> > Iam porting Linux 2.4.17 on MPC8260ADS. I had already working
> > Linux-2.4.1 version on MPC8260ADS board.
>
> There should be very minimal changes required to support the 8260ADS,
> just a few memory mapping initializations.  Everything else is generic
> to all of the other 8260 boards that are supported.

[KAMAL]:
All memory mapping is handled correctly.
SDRAM is mapped to 0xC0000000 from 0x00000000
Flash is mapped to 0xFF800000 from 0xFF800000
Board control/status register is mapped to 0xF0100000 from 0x04500000
IMMR is mapped to 0xF0000000 from 0x04700000

Iam using BATs to do this (BAT0 and BAT1)

> > I had rather taken an tedious process of identifying the problem by
> > glowing LEDs present on the board. I have identify the location of the
> > problem.
>
> Well....think about this for a moment......In order to flash the LEDs
> you need access to the board control register.  Once you initialize
> the MMU for Linux, these mappings are gone and you need to set them
> up again within the Linux memory map.  There are several memory map
> transistions during the start up of Linux.  Very early in the start
> up code it enables the MMU and only maps a small portion of real
> memory.  You won't be able to access LEDs after this point.

[KAMAL]:
After turning on MMU, iam using the LED code to flash leds and it is
working. Memory map of board control status register after turning on MMU is
0xf0100000. Only at this point it won't.

> > I checked the value of cur_cpu_spec[0] pointer. It was zero.
>
> How did you check this?  The processor is running with caches enabled,
> this pointer is initialized during the start up.  If you dumped out
> main memory after the crash, I doubt it was written out of the cache.

[KAMAL]:
Led flashing code looks something like this
--- Code begins ---
lis r20, 0xf010
lis r21, 0
stw r21, 0(r20)
--- Code ends ---

I checked the value of cur_cpu_spec[0] pointer to be zero by putting a
condition for cur_cpu_spec[0] pointer and glow the led if it is true.

> > I also tried commenting this line as this was not there in 2.4.1
> > version. Here control went till this point in "head.S" code
>
> Not a good idea.  There are subtle changes happening all of the time,
> and the difference between 2.4.1 and 2.4.17 is quite a bit.
>
> I suspect your access to the LEDs is crashing due to memory mapping
> changes, and taking you down the wrong path.

[KAMAL]:
Is there any other way of debugging this. I have PowerTAP emulator to use
and PPCBOOT running on the board.

> As I said, there should be very minimal board specific changes
> required.  A header file in arch/ppc/platforms, some updates to the
> bootloader, ensure the IMMR is set to 0xf0000000 before calling the
> kernel and you should have a console prompt.  If you want to access
> other board control registers, they will have to be ioremapped()
> somewhere in the kernel before you use them.

[KAMAL]:
Even i was under the impression that there will be very minimal BSP changes
required until i hit upon this problem.
IMMR is located at 0xf0000000 before calling the kernel.

>         -- Dan

Thanks in advance,
with rgds,
kamal


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem porting 2.4.17 linux to MPC8260ADS

[Shen Rong]

----- Original Message -----
From: "Kamalesh B" <kamal@tataelxsi.co.in>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Monday, February 24, 2003 2:45 PM
Subject: Re: Problem porting 2.4.17 linux to MPC8260ADS


> [KAMAL]:
> All memory mapping is handled correctly.
> SDRAM is mapped to 0xC0000000 from 0x00000000
> Flash is mapped to 0xFF800000 from 0xFF800000
> Board control/status register is mapped to 0xF0100000 from 0x04500000
> IMMR is mapped to 0xF0000000 from 0x04700000
>
> Iam using BATs to do this (BAT0 and BAT1)
How do you map the above, in PPCBoot or Linux?
If in Linux, BAT0 and BAT1 is not enough to map Flash & BCSR & IMMR.
Linux will map the IMMR automatically(in m8260_setup.c), and you'd better to
set the IMMR to be physically at 0xf0000000.

> After turning on MMU, iam using the LED code to flash leds and it is
> working. Memory map of board control status register after turning on MMU
is
> 0xf0100000. Only at this point it won't.
Remember, if you manually map the BCSR in head.S before start_kernel,
you will lost this map after the MMU fully inited(after start_kernel).
That's to say
LED not flashing doesn't mean Linux crashes. In fact, programming the LED
at the original address will likely crash Linux.

>
> > > I checked the value of cur_cpu_spec[0] pointer. It was zero.
If you are sure that the cur_cpu_spec[0] is NULL, then you sould check
the setup.c:early_init().  cur_cpu_spec is set by identify_cpu(). Check to
see what value it sets. early_init() runs with the stack address set by
ppcboot.

> Is there any other way of debugging this. I have PowerTAP emulator to use
> and PPCBOOT running on the board.
It will be good to use a emulator, but I have no experience with PowerTAP.

> > As I said, there should be very minimal board specific changes
> > required.  A header file in arch/ppc/platforms, some updates to the
> > bootloader, ensure the IMMR is set to 0xf0000000 before calling the
> > kernel and you should have a console prompt.  If you want to access
> > other board control registers, they will have to be ioremapped()
> > somewhere in the kernel before you use them.
Remember what dan has said.


Shenrong


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RAMDISK

[Kamalesh B]

Hello,

Right now, iam working booting Linux 2.4.1 on MPC8260ADS. Iam using NFS
option to boot the linux. Mount point is on the host PC.

Iam using PPCBOOT bootloader.

Command line argument for linux given is
root=/dev/nfs    nfsaddrs=<targetip>:<serverip>

My query is
1. How to boot linux-2.4.1 using root file system rather than using
network file system?
2. How to make ramdisk(root fs) part of linux kernel? DO i need to
change some makefiles or config options?
3. How to remove dependency of nfs to boot-up LINUX i.e, OS image should
boot in standalone setup?

thanks in advance,
with rgds,
kamal

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RAMDISK

[Wolfgang Denk]

In message <3E5EF447.3B9088D7@tataelxsi.co.in> you wrote:
>
> Command line argument for linux given is
> root=/dev/nfs    nfsaddrs=<targetip>:<serverip>
>
> My query is
> 1. How to boot linux-2.4.1 using root file system rather than using
> network file system?

You always use a "root filesystem". With your  option,  you  mount  a
filesystem exported by your NFS server as root filesystem.

I guess you want to mount a ramdisk as rootfilesystem. To do so, make
sure your "bootargs" variable contains the string "root=/dev/ram"

> 2. How to make ramdisk(root fs) part of linux kernel? DO i need to
> change some makefiles or config options?

Why would you want to make it part  of  the  kernel?  This  makes  no
sense.  If  you  mean how to combine the ramdisk image and the kernel
image into one image file,  then  please  see  the  multi-file  image
format of the "mkimage" tol that comes with PPCBoot.

> 3. How to remove dependency of nfs to boot-up LINUX i.e, OS image should
> boot in standalone setup?

Just do not use "root=/dev/nfs" in your "bootargs" settings.


Maybe you can get some more detailed help from reading the docs, like
http://www.denx.de/re/DPLG.html

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Without freedom of choice there is no creativity.
	-- Kirk, "The return of the Archons", stardate 3157.4

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem porting 2.4.17 linux to MPC8260ADS

[Dan Malek]

Kamalesh B wrote:

> [KAMAL]:
> All memory mapping is handled correctly.
> SDRAM is mapped to 0xC0000000 from 0x00000000
> Flash is mapped to 0xFF800000 from 0xFF800000
> Board control/status register is mapped to 0xF0100000 from 0x04500000
> IMMR is mapped to 0xF0000000 from 0x04700000
>
> Iam using BATs to do this (BAT0 and BAT1)

If I understand correctly (and I may not), this isn't being done
correctly.  Linux is going to take over the BATs for it's own mapping.
It doesn't matter what you have set in them.

You must ensure the IMMR is physically mapped to 0xf0000000.  That is,
you have to change the IMMR register to this value, you can't use
a BAT to map this value to the virtual 0xf0000000 and then call Linux.

The SDRAM will be remapped by Linux to use the BAT 3/4 registers based
upon how much memory you tell it is available in the board descriptor
structure.

The Flash and board control register will have to be mapped using ioremap()
and you will have to use the subsequent returned virtual address to
access these regions.



> [KAMAL]:
> After turning on MMU, iam using the LED code to flash leds and it is
> working. Memory map of board control status register after turning on MMU is
> 0xf0100000. Only at this point it won't.

No, they are not mapped there.  The only thing Linux knows about early
in the kernel is a small portion of the ram.  Linux completely changes the
MMU mapping, it doesn't matter what you have mapped when you call the kernel.
Your board control registers are not mapped any longer shortly after you
call the Linux kernel.


> [KAMAL]:
> Led flashing code looks something like this
> --- Code begins ---
> lis r20, 0xf010
> lis r21, 0
> stw r21, 0(r20)
> --- Code ends ---

That will crash the kernel shortly after you start it.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Problem porting 2.4.17 linux to MPC8260ADS

[Meszaros Lajos]

You have to initialize memory controller to certain
addresses BEFORE any use of BATs, ioremap etc.
For example
  -BR1/OR1 for BCSR
  -BR5/OR5 for ATM
  -IMMR
  all of them anywhere above 0xf0000000.

So You can use these addresses with or without MMU
at same address. ( phys = virtual !!!)

Best Regards
  Ludwig


> -----Eredeti uzenet-----
> Felado: Kamalesh B [mailto:kamal@tataelxsi.co.in]
> Kuldve: Friday, February 21, 2003 5:16 PM
> Cimzett: Coray Tate; linuxppc-embedded@lists.linuxppc.org
> Targy: Problem porting 2.4.17 linux to MPC8260ADS
[snip]

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/