LinuxPPC on FADS

LinuxPPC on FADS

[Thomas E. Arvanitis]

Hello All,

I am trying Linux-2.2.0-pre7 (provided by Dan) on a FADS-860SAR with 4MB
DRAM. After a few modifications, I am now up to the point where I boot ok
and kernel runs execve for "init". 

I use initrd, because NFS_ROOT (as I have read in the list's archive)
just doesn't work (is that true by the way? any news on that?), and I
personally have reached a dead-end: although root over NFS mounted ok,
never worked properly after that.
In the initrd case, ramdisk image is based on mbxroot.min (By Dan
again). I boot with the following args:

root=/dev/ram ramdsik_size=1536 ip=###.###.###.### init=/bin/sh

So what I get is:
- kernel uncompresses fine
- uart and ethernet initialize ok
- ramdisk also starts up ok
- ramdisk is uncompressed ok and mounted
- unused memory (28k init) is freed
- elf proccessing of sh is done also (I think) normally

After or around setup_arg_pages the kernel starts behaving realy weirdly.
Either it just hangs or I get a panic for a "page fault in interrupt".
In almost all cases I find that memory especially in the range of
0x300-0x1200 (ISRs) is strangely modified. In many places I find instead 
of expected code (e.g. EXCEPTION PROLOG instructions) virtual addresses or
physical addresses numbers. It seems like it goes crazy running arround
and writting where it shouldn't.

Has anyone any idea what's going on? Has anybody seen something like that
again?

Thanks for your help,
-Thomas.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: LinuxPPC on FADS

[Helmut Buchsbaum]

Hello Thomas!

The behaviour you describe is nearly the same I had on my FADS823.

But I'm glad to announce I've my FADS now up and running with a kernel
based on Dan's 2.2.0-pre7 tarball.
After a few months I took up the work on my FADS-Linux kernel again and
I tracked down the problem I had beyond that SET_PAGE_DIR macro, where
the M_TWB is set.
I discovered that I get a TLB miss with a zero pte when accessing the
ethernet controller (yes I boot via Root-NFS and it works great!!) and
somehow do_page_fault() can't build an appropriate entry for this
I/O-region (should it?). Since I'm not a Linux-MM guru I circumvented
that situation by reserving two TLB entries in arch/ppc/kernel/head.S:


......

#if defined(CONFIG_MBX) || defined(CONFIG_RPXLITE)
#define BOOT_IMMR       0xfa000000
#endif
#ifdef CONFIG_BSEIP
#define BOOT_IMMR       0xff000000
#endif
#ifdef CONFIG_FADS
#define BOOT_IMMR       0x02000000
#endif
        /* Map another 8 MByte at 0xfa000000 to get the processor
         * internal registers (among other things).
         */
#ifndef CONFIG_FADS
        lis     r8, BOOT_IMMR@h         /* Create vaddr for TLB */
        ori     r8, r8, MD_EVALID       /* Mark it valid */
        mtspr   MD_EPN, r8
        li      r8, MD_PS8MEG           /* Set 8M byte page */
        ori     r8, r8, MD_SVALID       /* Make it valid */
        mtspr   MD_TWC, r8
        lis     r8, BOOT_IMMR@h         /* Create paddr for TLB */
        ori     r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */
        mtspr   MD_RPN, r8

#else
        bl      fadsForceIO
#endif

        
        /* Since the cache is enabled according to the information we
         * just loaded into the TLB, invalidate and enable the caches
here.
         * We should probably check/set other modes....later.
         */
        lis     r8, IDC_INVALL@h
        mtspr   IC_CST, r8
        mtspr   DC_CST, r8
        lis     r8, IDC_ENABLE@h
        mtspr   IC_CST, r8

.....

fadsForceIO:    
    mfspr   r8,MD_CTR
    ori     r8,r8,0700      /* set TBL idx to 7 */
    mtspr   MD_CTR, r8
    lis     r8, BOOT_IMMR@h         /* Create vaddr for TLB */
    ori     r8, r8, MD_EVALID       /* Mark it valid */
    mtspr   MD_EPN, r8
    li      r8, MD_PS8MEG           /* Set 8M byte page */
    ori     r8, r8, MD_SVALID       /* Make it valid */
    mtspr   MD_TWC, r8
    lis     r8, BOOT_IMMR@h         /* Create paddr for TLB */
    ori     r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */
    mtspr   MD_RPN, r8
    mfspr   r8,MD_CTR
    oris    r8,r8,0x0800    /* set RSV2D */
    mtspr   MD_CTR, r8
    blr



Additionally I use the tlbia macro for the 603, since I'm quite sure the
tlbia instruction of an 8xx deletes my fixed entry, too.

That's been all what I've done to be able to start /sbin/init.
In fact I'm not really happy with such a hack and I'd appriciate a
proper solution. BTW, I don't understand why this kind of problem does
not appear on the other boards(?!).


BTW, I added some FADS specific parts by extending Dan's #define's and
configs for RPXLITE, BSEIP and MBX.


Hope it helps,
Helmut

P.S.: I'd like to contribute my minor changes for the FADS
(configuration, board setup), but how? 
-- 
*********************************************************
* Helmut Buchsbaum               * Siemens AG Austria   *
* Tel:   ++43-1-1707-36686       * EZE PN 5             *
* Fax:   ++43-1-1707-55169       * Erdberger Laende 26  *
*                                * A-1030 Vienna/Europe *
*********************************************************
* mailto:Helmut.Buchsbaum@siemens.at                    *
*        buc@eze22.siemens.co.at                        *
*********************************************************

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: LinuxPPC on FADS

[Thomas E. Arvanitis]

That was a good hack! :-)

It also worked for me instantly! Both for NFS-root and initrd.
Every weird behavior has just disappeared. 
Although with initrd I run out of memory soon, this is rather normal,
I suppose, with only 4Mb DRAM. Perhaps a smaller shell than bash will
improve the situation...

I've been banging my head with this problem for almost 2 weeks...
Thanks a lot Helmut!

-Thomas.



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: LinuxPPC on FADS

[Magnus Damm]

That has been one of my problems since october... =)

Now is linux running with root on ATA-Flash!

Question:

Where can I find information about linux memory management?

Thank you! 

/ Magnus





[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: LinuxPPC on FADS

[Helmut Buchsbaum]

Hello Magnus!

Magnus Damm wrote:
> 
> That has been one of my problems since october... =)
> 
> Now is linux running with root on ATA-Flash!

This what I'd like to do, too! But what about the 823-PCMCIA controller
support?
What's your configuration?
I once spent some hours to adapt Dan's FADSROM for the 860 to my 823,
but unfortunately I didn't succeed due to problems talking to the PCMCIA
hardware!

> 
> Question:
> 
> Where can I find information about linux memory management?
> 

Try http://humbolt.geo.uu.nl/Linux-MM/ for a start!


-- 
*********************************************************
* Helmut Buchsbaum               * Siemens AG Austria   *
* Tel:   ++43-1-1707-36686       * EZE PN 5             *
* Fax:   ++43-1-1707-55169       * Erdberger Laende 26  *
*                                * A-1030 Vienna/Europe *
*********************************************************
* mailto:Helmut.Buchsbaum@siemens.at                    *
*        buc@eze22.siemens.co.at                        *
*********************************************************

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]