Jivin Raul Aguaviva lays it down ...
> Hello,
>
> I've been debugging this issue, and I have a few questions:
>
> 1) the kernel is launched with an empty command line, is this OK?
Yes, the first tty to register console support automatically becomes
the console.
The blkmem/mtd driver set ROOT appropriately so that the root filesystem
is found, everything else is controled by inittab and rc scripts.
> 2) Lets see if I get this right, the kernel boots up, then it creates a
> ramdisk and then loads there the romfs, am I correct?
No, the romfs is located in "ram" at the end of the kernel and reserved
and mounted from there. The ROOT device is pointed at the appropriate
flash device driver (ie., blkmem/mtd).
> 3) rd_doload never becomes 1, so the ramdisk is not loaded. Is this OK?
yes, initrd and ramdisks havenothing to do with the boot.
> 4) setting rd_doload to 1 in rd.c didn't help, the rd_load_disk()
> function returns because MAJOR(ROOT_DEV) != FLOPPY_MAJOR, and the ramdisk
> is not loaded.
> see below the function I'm talking about
Somehow the filesystem image at the end of the kernel in RAM is either
corrupted or not located there. Start from there and watch it.
Cheers,
Davidm
> static void rd_load_disk(int n)
> {
>
> printk("rd_load_disk, doload: %i\n",rd_doload);
>
> #ifdef CONFIG_BLK_DEV_INITRD
> extern kdev_t real_root_dev;
> #endif
>
> if (rd_doload == 0)
> return;
>
>
> printk("rd_load_disk %x %x\n",MAJOR(ROOT_DEV), FLOPPY_MAJOR);
>
> if (MAJOR(ROOT_DEV) != FLOPPY_MAJOR
> #ifdef CONFIG_BLK_DEV_INITRD
> && MAJOR(real_root_dev) != FLOPPY_MAJOR
> #endif
> )
> return;
>
> printk("rd_load_disk 3\n");
>
> if (rd_prompt) {
> #ifdef CONFIG_BLK_DEV_FD
> floppy_eject();
> #endif
> printk(KERN_NOTICE
> "VFS: Insert root floppy disk to be loaded into ramdisk
> and press ENTER\n");
> wait_for_keypress();
> }
>
> printk("rd_load_disk 4: rd_image_start:%u n:%i\n",rd_image_start,n);
> rd_load_image(ROOT_DEV,rd_image_start,n);
>
> }
> --- Raul Aguaviva <[EMAIL PROTECTED]> wrote:
>
> > Still no luck,
> >
> > I went back to kernel 2.0.x, my romfs is 83kb and i still get the kernel
> > panic
> > (full log poster below)
> >
> > image.bin is 464000
> > linux.data 57776
> > linux.text 322256
> > rimfs.img 83968
> >
> >
> > Any ideas?
> > thanks
> > Raul
> >
> >
> >
> -----------8<-----------8<-----------8<-----------8<-----------8<-----------8<
> >
> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFRBCK
> > 68EZ328 DragonBallEZ support (C) 1999 Rt-Control, Inc
> >
> >
> > uClinux/MC68EZ328
> > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
> > PalmV support by Lineo Inc. <[EMAIL PROTECTED]>
> > Console driver (without boot console): mono mc68328 40x26, 1 virtual console
> > (ma
> > x 63)
> > Calibrating delay loop.. ok - 1.36 BogoMIPS
> > Memory available: 1420k/1716k RAM, 0k/0k ROM (314k kernel code, 612k data)
> > Swansea University Computer Society NET3.035 for Linux 2.0
> > NET3: Unix domain sockets 0.13 for Linux NET3.035.
> > uClinux version 2.0.39.uc2 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315
> > (rele
> > ase)(ColdFire patches - 20010318 from
> > http://fiddes.net/coldfire/)(-msep-data
> > pa
> > tches)) 7 Sun Jan 14 23:54:06 CET 2007
> > MC68328 serial driver version 1.00
> > ttyS0 at 0xfffff900 (irq = 64) is a builtin MC68328 UART
> > Ramdisk driver initialized : 16 ramdisks of 4096K size
> > VFS: Cannot open root device 1f:00
> > Kernel panic: VFS: Unable to mount root fs on 1f:00
> >
> -----------8<-----------8<-----------8<-----------8<-----------8<-----------8<
> >
> > --- David McCullough <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Jivin Raul Aguaviva lays it down ...
> > > > David, I noticed that the PRC contains strings like the ones below:
> > > >
> > > >
> > >
> >
> --------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/sched.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/asm/pgalloc.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/highmem.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/dcache.h
> > kernel
> > > BUG
> > > > at %s:%d!
> > > > BUG! /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/sched.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/asm/pgalloc.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/highmem.h
> > major
> > > > minor #blocks name
> > > >
> > > > %4d %4d %10d %s
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/dcache.h
> > kernel
> > > BUG
> > > > at %s:%d!
> > > > BUG! /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/sched.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/asm/pgalloc.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/highmem.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/dcache.h
> > kernel
> > > BUG
> > > > at %s:%d!
> > > > BUG! /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/sched.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/asm/pgalloc.h
> > > > /home/raul/palm/uClinux-dist-old/linux-2.4.x/include/linux/highmem.h B
> > > >
> > >
> >
> --------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<
> > > >
> > > > the path I'm suing to compile the prc is quite long and this makes the
> > prc
> > > > size to be 800kb.
> > > > My question is, why are those paths stored in the PRC binary? This
> > > > looks
> > > to me
> > > > like a debug build...
> > > >
> > > > In the, I believe, unlikely event that these strings had to live in the
> > > prc
> > > > maybe I should move the uclinux directory so the path is as short as
> > > possible
> > > >
> > > >
> > > > Any thoughts?
> > >
> > >
> > > Doesn't sound good that they are in there. Anything that can remove
> > > them would be a good thing IMO. At least it would improve load time ;-)
> > >
> > > Cheers,
> > > Davidm
> > >
> > >
> > > > --- David McCullough <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >
> > > > > Jivin Raul Aguaviva lays it down ...
> > > > > >
> > > > > > Again this problem, yes :-) I read many emails that explain what
> > this
> > > > > error is
> > > > > > but none explains how to fix it.
> > > > > >
> > > > > > What exactly do I have to change in the source code to fix this
> > > problem on
> > > > > a
> > > > > > Palm IIIx?
> > > > > >
> > > > > > I followed the instructions step by step in:
> > > > > > http://www.ucdot.org/archive/deep/deeply-embedded-linux.html
> > > > > >
> > > > > > The uClinuxPalm.prc I get does have the romfs.img at the offset
> > > 0x5eef2
> > > > > >
> > > > > > I also read:
> > > > > > http://www.ucdot.org/article.pl?sid=03/01/11/1049210&mode=thread
> > > > > > but it didn't help.
> > > > >
> > > > > Try reducing the size of your romfs and see if that helps:
> > > > >
> > > > > rm romfs/bin/....
> > > > > make image
> > > > > try reloading
> > > > >
> > > > > You need to keep init and sh, but most other things can go. I have
> > > > > seen romfs size changes affect the loading on the .prc,
> > > > >
> > > > > Cheers,
> > > > > Davidm
> > > > >
> > > > > --
> > > > > David McCullough, [EMAIL PROTECTED], Ph:+61
> > > 734352815
> > > > > Secure Computing - SnapGear http://www.uCdot.org
> > > http://www.cyberguard.com
> > > > > _______________________________________________
> > > > > uClinux-dev mailing list
> > > > > [email protected]
> > > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > > This message was resent by [email protected]
> > > > > To unsubscribe see:
> > > > > http://mailman.uclinux.org/mailman/options/uclinux-dev
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ____________________________________________________________________________________
> > > > Don't pick lemons.
> > > > See all the new 2007 cars at Yahoo! Autos.
> > > > http://autos.yahoo.com/new_cars.html
> > > > _______________________________________________
> > > > uClinux-dev mailing list
> > > > [email protected]
> > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > This message was resent by [email protected]
> > > > To unsubscribe see:
> > > > http://mailman.uclinux.org/mailman/options/uclinux-dev
> > >
> > > --
> > > David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
> > > Secure Computing - SnapGear http://www.uCdot.org
> > > http://www.cyberguard.com
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > [email protected]
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by [email protected]
> > > To unsubscribe see:
> > > http://mailman.uclinux.org/mailman/options/uclinux-dev
> > >
> >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Cheap talk?
> > Check out Yahoo! Messenger's low PC-to-Phone call rates.
> > http://voice.yahoo.com
> > _______________________________________________
> > uClinux-dev mailing list
> > [email protected]
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by [email protected]
> >
> === message truncated ===
>
>
>
>
> ____________________________________________________________________________________
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
> _______________________________________________
> uClinux-dev mailing list
> [email protected]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [email protected]
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
