* PCMCIA on the FADS @ 2000-10-11 16:05 Paolo Scaffardi 2000-10-13 19:47 ` <kernel-image-name> Zhaobin Zhu 0 siblings, 1 reply; 6+ messages in thread From: Paolo Scaffardi @ 2000-10-11 16:05 UTC (permalink / raw) To: linuxppc-emb 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* <kernel-image-name> 2000-10-11 16:05 PCMCIA on the FADS Paolo Scaffardi @ 2000-10-13 19:47 ` Zhaobin Zhu 2000-10-13 20:07 ` NFS boot hangs Zhaobin Zhu 2000-10-13 20:29 ` <kernel-image-name> Mark A. Greer 0 siblings, 2 replies; 6+ messages in thread From: Zhaobin Zhu @ 2000-10-13 19:47 UTC (permalink / raw) Cc: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* NFS boot hangs 2000-10-13 19:47 ` <kernel-image-name> Zhaobin Zhu @ 2000-10-13 20:07 ` Zhaobin Zhu 2000-10-13 20:29 ` <kernel-image-name> Mark A. Greer 1 sibling, 0 replies; 6+ messages in thread From: Zhaobin Zhu @ 2000-10-13 20:07 UTC (permalink / raw) To: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: <kernel-image-name> 2000-10-13 19:47 ` <kernel-image-name> Zhaobin Zhu 2000-10-13 20:07 ` NFS boot hangs Zhaobin Zhu @ 2000-10-13 20:29 ` Mark A. Greer 2000-10-24 12:55 ` <kernel-image-name> Topi Kanerva 1 sibling, 1 reply; 6+ messages in thread From: Mark A. Greer @ 2000-10-13 20:29 UTC (permalink / raw) To: Zhaobin Zhu; +Cc: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: <kernel-image-name> 2000-10-13 20:29 ` <kernel-image-name> Mark A. Greer @ 2000-10-24 12:55 ` Topi Kanerva 2000-10-24 21:04 ` <kernel-image-name> Mark A. Greer 0 siblings, 1 reply; 6+ messages in thread From: Topi Kanerva @ 2000-10-24 12:55 UTC (permalink / raw) To: Mark A. Greer; +Cc: Zhaobin Zhu, linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: <kernel-image-name> 2000-10-24 12:55 ` <kernel-image-name> Topi Kanerva @ 2000-10-24 21:04 ` Mark A. Greer 0 siblings, 0 replies; 6+ messages in thread From: Mark A. Greer @ 2000-10-24 21:04 UTC (permalink / raw) To: Topi Kanerva; +Cc: Zhaobin Zhu, linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-10-24 21:04 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2000-10-11 16:05 PCMCIA on the FADS Paolo Scaffardi 2000-10-13 19:47 ` <kernel-image-name> Zhaobin Zhu 2000-10-13 20:07 ` NFS boot hangs Zhaobin Zhu 2000-10-13 20:29 ` <kernel-image-name> Mark A. Greer 2000-10-24 12:55 ` <kernel-image-name> Topi Kanerva 2000-10-24 21:04 ` <kernel-image-name> Mark A. Greer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).