PCMCIA on the FADS

PCMCIA on the FADS

[Paolo Scaffardi]

I am trying to make the Damm's PCMCIA socket drivers work on my FADS823.

I think the problem is related to the ioremapping of _IO_BASE.

What value should i give to it? I tried giving it an unused value
(0x02200000 on my FADS), doing into arch/ppc/mm/init.c a simple
ioremap(_IO_BASE, _IO_BASE_SIZE) where IO_BASE_SIZE is 64*1024, but when i
load m8xx_pcmcia.o i get this error:

8xx_pcmcia: Version 0.03, 14-Feb-2000, Magnus Damm
8xx_pcmcia: FADS using SLOT_B with IRQ 13.
IP: C400B0AC XER: A000624E and so on.....
TASK = c0640000[17] 'insmod' mm->pgd c032f000

What is the problem? :-o

- may the pinguin b with u -

Have a nice day,
Paolo Scaffardi.
AIRVENT SAM s.p.a. - RIMINI - ITALY


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

<kernel-image-name>

[Zhaobin Zhu]

Hi,

I am setting up host (Redhat 6.2 i386) for sp7400 boot over NFS.

I do this following instructions on manual for Hardhat CDK 1.2

When configuring TFTP, to create a symbolic link to boot file
in /tftpboot,

ln -s /opt/hardhat/devkit/ppc/82xx/target/boot/<kernel-image-name>
<kernel-image-name>

What should I give to <kernel-image-name> ?

When I do "make zImage", I got two binaries, vmlinux and zvmlinux. I also
create a S-record file.
Which of the 3 files do I use as <kernel-image-name> ?

BTW, what is the role of tftp in kernel boot on NFS ?
I don't see any tftp message when kernel is booting ?

Thanks,

--
 Zhaobin Zhu
 zzhu@emc.com


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

NFS boot hangs

[Zhaobin Zhu]

Hi,

I finally got Hardhat linux boot on NFS.

I can play a while under sh-2.03# prompt, something like
ls; vi; ./hello, etc.

Suddenly my RH62 host and sp7400 target hang.
I can ping both of them.

Anybody has such an experience before ? Any clue what problem it is ?

Thanks,
--
 Zhaobin Zhu
 zzhu@emc.com


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

Re: <kernel-image-name>

[Mark A. Greer]

Zhaobin Zhu wrote:

> Hi,
>
> I am setting up host (Redhat 6.2 i386) for sp7400 boot over NFS.
>
> I do this following instructions on manual for Hardhat CDK 1.2
>
> When configuring TFTP, to create a symbolic link to boot file
> in /tftpboot,
>
> ln -s /opt/hardhat/devkit/ppc/82xx/target/boot/<kernel-image-name>
> <kernel-image-name>
>
> What should I give to <kernel-image-name> ?
>
> When I do "make zImage", I got two binaries, vmlinux and zvmlinux. I also
> create a S-record file.
> Which of the 3 files do I use as <kernel-image-name> ?
>
> BTW, what is the role of tftp in kernel boot on NFS ?
> I don't see any tftp message when kernel is booting ?

I may have misunderstood your email but if I did understand the email
correctly, you have some incorrect expectations of "booting over NFS".

You can do a "network boot" and then "NFS mount" the root filesystem but DINK
doesn't support net boot on the sandpoint so you can NOT actually BOOT over
the network.  Just as bad, DINK doesn't support booting from a disk either so
you can't actually boot from an IDE drive (even though an IDE ctlr is embedded
on that board).  You _can_ put a root filesystem on an IDE drive and use that
for your root filesystem but you have the same issue of getting the kernel
into memory in the first place.

 You must get the kernel into memory some other way.  That's were DINK's
download over serial, a JTAG probe, or putting the kernel into flash comes
in.  You don't actually get the kernel itself over NFS (chicken & egg--you
need a kernel to NFS mount so you can't use NFS to get the kernel).

When people (such as myself) say "booting over NFS" we usually mean simply
mounting the root filesystem over NFS.  You need firmware support to get the
kernel from over the network (net boot) which DINK doesn't have.

I recommend building a kernel you're happy with (the one in
arch/ppc/boot/zvmlinux), stripping off the first 64KB, and putting it into
flash (do NOT overwrite DINK).  When you power on the system, let DINK run,
then run the zvmlinux at the address you burned it into flash.  You can have
DINK automatically jump to an address with the "env" cmd, I believe.  Someone
else will have to help you with the DINK cmds to get your kernel into flash.

I think my response to a previous email may have caused this confusion.  If
so, I apologize.  I meant to say, I "NFS mount the root filesystem" all the
time but I download the actual kernel into memory using my JTAG probe.

Mark


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

Re: <kernel-image-name>

[Topi Kanerva]

More experimentation with 2.4.0-test2 sandpoint kernel...
Because I couldn't make nfs booting to work (always the same oops after
mounting root...) I decided to try to mount an initrd instead. So, I took
the debian rootdisk image
(.../disks-powerpc/current/powermac/ramdisk.image.gz) and copied that to
arch/ppc/boot and then re-made the kernel with make zImage.initrd and then
zsrec'd the  zvmlinux.initrd that the make process left lying around
there... Then upload the stuff over to DINK. However, on bootup I get this:

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 4194301k freed

and afterwards the VFS issues a kernel panic since it cannot mount root fs
on 01:00 (/dev/ram)
...
now, should the ram disk work, or am I doing something fundamentally wrong
here? I've config'd the kernel to use both CONFIG_BLK_DEV_RAM and
CONFIG_BLK_DEV_INITRD so I suppose ramdisks should work. The kernel
bootloader even seems to see the piggybacked ramdisk:

DINK32/MPC7400@46u>>go 200000
loaded at:     00200000 00214E20
relocated to:  00800000 00814E20
board data at: 0080E314 00814D20
relocated to:  0080E314 00814D20
zimage at:     0020B000 002932FE
relocated to:  00815000 0089D2FE
initrd at:     002932FE 003FB2FE
relocated to:  0089D2FE 00A052FE
avail ram:     00400000 00800000

Linux/PPC load: root=/dev/ram


Any ideas what I'm doing wrong here? I've been up all day so when you're
really tired, there's something really stupid I'm forgetting right now...

I don't know why, but I seem to be the only one that cannot even make the
damn stupid sandpoint to boot at *all*. Maybe I should get a job cleaning
toilets instead...


-topi


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

Re: <kernel-image-name>

[Mark A. Greer]

Topi,

I don't know what you're nfs problems are.

initrd is broken.  In the 2.4.0-test kernel (and probably others), some
necessary lines were removed from arch/ppc/boot/head.S.  I believe they have
been added back in the more recent source.  Here is a patch:

--- /opt/hardhat/devkit/lsp/sp8240/linux-2.4.0-test2/arch/ppc/boot/head.S
Sat Nov 27 16:41:59 1999
+++ head.S      Tue Oct 24 13:44:56 2000
@@ -112,6 +112,14 @@
        cmpi    0,r2,0
        bne     00b

+       /* r4,r5 have initrd_start, size */
+       lis     r2,initrd_start@h
+       ori     r2,r2,initrd_start@l
+       lwz     r4,0(r2)
+       lis     r2,initrd_end@h
+       ori     r2,r2,initrd_end@l
+       lwz     r5,0(r2)
+
        /* tell kernel we're prep */
        /*
         * get start address of kernel code which is stored as a coff



Also, the sandpoint_setup_arch() routine in arch/ppc/kernel/sandpoint_setup.c
needs to be fixed.  Change the SCSI_CDROM_MAJOR to RAMDISK_MAJOR.

These hacks should get your ramdisk going...

Mark
--


> Linux/PPC load: root=/dev/ram
>
> Any ideas what I'm doing wrong here? I've been up all day so when you're
> really tired, there's something really stupid I'm forgetting right now...
>
> I don't know why, but I seem to be the only one that cannot even make the
> damn stupid sandpoint to boot at *all*. Maybe I should get a job cleaning
> toilets instead...
>
> -topi

--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ  85282


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