Jivin Wolfgang Wegner lays it down ...
> Hi David,
>
> On Wed, Nov 28, 2007 at 08:39:38PM +1000, David McCullough wrote:
> >
> > Ok, a lot of things are getting mixed up here. You do not need MTD for
> > initramfs and you do not need to enable sysfs either.
>
> hmm... but Juan Alberto's log shows some "RAM-based romfs" being
> initialized during MTD initialization, or what is this?
He has his system setup differently and is using MTD for his root
ramdisk I suspect rather than using initrd (option 2 I listed).
> > You should always get all you boot messages regardless of the console
> > device. Check that your serial driver specifies CON_PRINTBUFFER in it's
> > flags. This should mean that it will print all the buffered printk
> > support when it comes online.
>
> The driver (mcfserial.c) does have CON_PRINTBUFFER in it's flags.
Ok.
> Is "earlyprintk" still needed as a boot parameter? I read this somewhere...
> And if so, should it be a seperate flag or does it belong to the
> "console=" blurb?
I have never used it. On a initramfs system I was running here my
kernel command line is:
CONFIG_CMDLINE="console=ttyS0,38400 rdinit=/bin/init
I have always has full serial console output.
> > > (Another strange thing I just notice is that I forgot to change the kernel
> > > command line and the kernel is not able to mount the romfs in flash when
> > > I enable initrd, although the root device printed is correct and the
> > > partition listing is ok, too...)
> >
> > That is a concern. If the MTD mapping is correct and you haven't forced
> > the wrong fstype, or removed the filesystem type from the kernel, then
> > it should definately be able to mount the filesystem in flash. Perhaps
> > you should check the fs is where you thing it is ?
> >
> > Is there any chance you are having RAM issues ? I though you said it
> > was all working fine on an older kernel.
>
> I do not think so - when the kernel comes up, everything seems to be
> fine.
> In case my above statement was misunderstanding: when I leave out the
> whole "initrd" configuration, my /dev/mtdblock3 is mounted correctly as
> the root fs, but when I configure the kernel for initrd, the log looks
> identical including the partition scan, but the kernel complains it can
> not mount this filesystem - so it seems there is already something switched
> over for initramfs, but not completely?
Hmm, yes, it's not happy with the initramfs.
> There seems to be some problem with either generating the cpio archive
> or its size - when I use my old initramfs source directory (containing
> only 1 application and some device files), everything is OK, using the
> new directory with some uClinux applications installed mounting the
> initramfs fails.
Did you try rebuilding it using the commands I included in the last email ?
> new:
> colinux:/projects/new2/uClinux-dist-20071107# du -sk romfs/
> 1568 romfs/
>
> old:
> colinux:/projects/new2/uClinux-dist-20071107# du -sk
> ../../local/uClinux-dist-test/initramfs_test
> 328 ../../local/uClinux-dist-test/initramfs_test
>
> This is from the kernel config:
> CONFIG_BLK_DEV_NBD=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
All looks ok, sizes are fine (4MB).
> Thank you for your hints and insights anyways, that seems to make
> things clearer to me!
It won't make sense until it works ;-)
Cheers,
Davidm
> > > > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> > > > FEC ENET Version 0.2
> > > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874
> > > > eth0: ethernet 00:cf:52:55:fc:bc
> > > > PPP generic driver version 2.4.2
> > > >
> > > > // *********************
> > > > uclinux[mtd]: RAM probe address=0x1b715c size=0x2d0000
> > > > Creating 1 MTD partitions on "RAM":
> > > > 0x00000000-0x002d0000 : "ROMfs"
> > > > mtd: Giving out device 0 to ROMfs
> > > > uclinux[mtd]: set ROMfs to be root filesystem
> > > > // *********************
> > > >
> > > > Number of erase regions: 3
> > > > Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
> > > > Primary Algorithm Table at 0040
> > > > Alternative Vendor Command Set: 0000 (None)
> > > > No Alternate Algorithm Table
> > > > Vcc Minimum: 2.7 V
> > > > Vcc Maximum: 3.6 V
> > > > No Vpp line
> > > > Typical byte/word write timeout: 8 µs
> > > > Maximum byte/word write timeout: 256 µs
> > > > Full buffer write not supported
> > > > Typical block erase timeout: 512 ms
> > > > Maximum block erase timeout: 8192 ms
> > > > Chip erase not supported
> > > > Device size: 0x800000 bytes (8 MiB)
> > > > Flash Device Interface description: 0x0002
> > > > - supports x8 and x16 via BYTE# with asynchronous interface
> > > > Max. bytes in buffer write: 0x1
> > > > Number of Erase Block Regions: 3
> > > > Erase Region #0: BlockSize 0x2000 bytes, 8 blocks
> > > > Erase Region #1: BlockSize 0x10000 bytes, 126 blocks
> > > > Erase Region #2: BlockSize 0x2000 bytes, 8 blocks
> > > > MCF5282 flash: Found 1 x16 devices at 0x0 in 16-bit bank
> > > > MCF5282 flash: Found 1 x16 devices at 0x800000 in 16-bit bank
> > > > Amd/Fujitsu Extended Query Table at 0x0040
> > > > MCF5282 flash: CFI does not contain boot bank location. Assuming top.
> > > > number of CFI chips: 2
> > > > cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> > > > MCF5282 flash device: 16MiB at 0xff000000
> > > > Creating 7 MTD partitions on "MCF5282 flash":
> > > > 0x00000000-0x00010000 : "loader(64KB)"
> > > > mtd: Giving out device 1 to loader(64KB)
> > > > 0x00010000-0x00400000 : "kernel (4032KB)"
> > > > mtd: Giving out device 2 to kernel (4032KB)
> > > > 0x00400000-0x00480000 : "UserSpace1 (/user/) (512KB)"
> > > > mtd: Giving out device 3 to UserSpace1 (/user/) (512KB)
> > > > 0x00480000-0x00500000 : "UserSpace2 (/user1/) (512KB)"
> > > > mtd: Giving out device 4 to UserSpace2 (/user1/) (512KB)
> > > > 0x00500000-0x00800000 : "UserSpace3 (/user2/) (3MB)"
> > > > mtd: Giving out device 5 to UserSpace3 (/user2/) (3MB)
> > > > 0x00800000-0x00c00000 : "UserSpace4 (/user3/) (4MB)"
> > > > mtd: Giving out device 6 to UserSpace4 (/user3/) (4MB)
> > > > 0x00c00000-0x01000000 : "UserSpace5 (/user4/) (4MB)"
> > > > mtd: Giving out device 7 to UserSpace5 (/user4/) (4MB)
> > > > Netfilter messages via NETLINK v0.30.
> > > > nf_conntrack version 0.5.0 (256 buckets, 2048 max)
> > > > IPv4 over IPv4 tunneling driver
> > > > GRE over IPv4 tunneling driver
> > > > ip_tables: (C) 2000-2006 Netfilter Core Team
> > > > TCP cubic registered
> > > > NET: Registered protocol family 1
> > > > NET: Registered protocol family 17
> > > >
> > > > // *********************
> > > > VFS: Mounted root (romfs filesystem) readonly.
> > > > // *********************
> > > >
> > > > Freeing unused kernel memory: 64k freed (0x195000 - 0x1a4000)
> > > >
> > > >
> > > >
> > > >
> > > > -----Mensaje original-----
> > > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > > En nombre de Wolfgang Wegner
> > > > Enviado el: miércoles, 28 de noviembre de 2007 8:35
> > > > Para: uClinux development list
> > > > Asunto: Re: [uClinux-dev] unable to use embedded initrd on MCF532x
> > > >
> > > > Hi Gavin,
> > > > On Wed, Nov 28, 2007 at 10:06:14AM +1300, Gavin Lambert wrote:
> > > > >
> > > > > So have you tried adding a root= option like it suggested? (I'm
> > > > > presuming one of the partitions listed above is the root partition;
> > > > > certainly you're not including the "root FS appended to kernel image"
> > > > > uClinux mapping
> > > > > driver.)
> > > >
> > > > I tried many different root= options of which I thought they might help.
> > > >
> > > > What is this "root FS appended to kernel image" driver you mention?
> > > > I can not find it anywhere, neither in the general configuration where
> > > > the
> > > > initramfs settings are nor in the MTD section.
> > > >
> > > > I am more and more confused - is initramfs in newer uClinux completely
> > > > different than in the older kernels? I thought it is ramfs and handled
> > > > by
> > > > ramdisk driver, and now you come up with a connection to mtd...?
> > > >
> > > > Regards,
> > > > Wolfgang
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> > > > _______________________________________________
> > > > 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
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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
