Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 01 Jun 2005 12:00 PM by  mikea@logicpd.com
is on board flash booting possible/feasible?
 18 Replies
Sort:
You are not authorized to post a reply.
Author Messages
tozyagcilar
New Member
New Member
Posts:


--
29 Mar 2005 02:35 PM
    Hello all,

    I am wondering if it is possible to boot linux from internal flash(on-board, 8 to 16MB) instead of tftp or CompactFlash. How hard would this be? and what needs to be done?

    I am assuming that the two partitions created on CF should somehow be created on the on-board flash also, since the kernel will be looking for the rootfs. How can this be done if at all? Is there a way of doing this without partioning?

    Any suggestions/ideas/opinions are welcome...

    Thanks!

    Talat,
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    18 Apr 2005 06:36 PM
    Yes, it is possible using the onboard flash, but you have to partition it so that the MTD system knows where the bits are. You need to partition the on-board flash into *three* parts, the first for LiLo, the second for the kernel, and the third for the root filesystem.

    To partition the flash, you'll have to find the MTD flash partition map in drivers/mtd/map/*.c that is compiled into the kernel(I don't have the source handy to point you specifically), but you'll need to supply a partition table that looks something like:

    #define LILO_SIZE (128<<10) // assume LiLo consumes 128KB of flash
    #define LILO_OFFSET 0 // offset from start of flash to LiLo
    #define KERNEL_OFFSET (LILO_OFFSET+LILO_SIZE) // offset to start of kernel
    #define KERNEL_SIZE (3<<20) // assume kernel needs 3Mb
    #define ROOTFS_SIZE ((16<<20)-(LILO_SIZE+KERNEL_SIZE) // rest of Flash
    #define ROOTFS_OFFSET (KERNEL_OFFSET+KERNEL_SIZE)
    static struct mtd_partition fire_engine_boot_partitions[] = {
    {
    name: "LiLo,
    size: LILO_SIZE,
    offset: LILO_OFFSET,
    mask_flags: MTD_WRITEABLE,
    },
    {
    name: "Kernel",
    size: KERNEL_SIZE,
    offset: KERNEL_OFFSET,
    mask_flags: MTD_WRITEABLE,
    },
    {
    name: "RootFS",
    size: ROOTFS_SIZE,
    offset: ROOTFS_OFFSET,
    },
    };

    This partitions the flash into three bits, the first that is for LiLo, the 2nd for the kernel, and the third for the rootfs. Don't worry about accidently overwriting either LiLo or the kernel from Linux since the 'mask_flags' prevents writing into those two partitions(assuming you *correctly* specify the sizes of each of those flash partitions).
    This also assumes you only have the one flash device.

    If you supply this as the parition table for your MTD driver, then on boot, you'll see three devices in /proc/mtd, /dev/mdtblock/[0-2], 0 being your bootloader, 1 being your kernel, and 2 being your root filesystem.

    Then you need to make a root filesystem on the host and copy it into the flash. You'll need mkfs.jffs2(assuming you want to use JFFS2 as your root filesystem type). Again, I don't have the source handle to verify, but mkfs.jffs2 is what you run pointing at a directory that contains the root filesystem and creates a file that holds the filesystem image, much the same way mkfs.ext2 does for a host linux system. Copy that root filesystem image created on the host by mkfs.jffs2 on the host onto the *target* flash device via some means(say an NFS mount on /mnt/nfs where /mnt/nfs is a directory that exists on your *target*), to the flash partition:

    mount -o nolock my.host.ip.addr:/mountable/directory/holding/rootfs.jfffs2 /mnt/nfs
    cat /mnt/nfs/rootfs.jffs2 > /dev/mtd/2

    Then you can mount that filesystem on the target(assuming /mnt/fs is a directory on the target you can mount on):

    mount -t jffs2 /dev/mtdblock/2 /mnt/fs

    And then peruse /mnt/fs to be sure it looks like the target rootfs that you want.

    If you get to this point and all /mnt/fs looks good, you can change your command line supplied to the kernel on boot to have "root=/dev/mtdblock2" and when you boot the kernel it *shoudl* ook there for the root filesystem, assuming that all of MTD(including the maps) are bult into the kernel (no modules allowed here).

    Once you can tftp a kernel to ram and boot it using the root filesytem from ram, you can copy the kernel to flash (at KERNEL_OFFSET) via LiLo, and then have LiLo branch to that address in flash to start the kernel at poweron. Again, I don't have the sources at hand to be sure, but I *think* that the kernel startup code is smart enough to copy itself out of flash into ram and continue as if you tftp'd it into ram and started it up there.

    This is just a rough outiline of the steps you'll need to do, and is hopefully enough to point you in the right direction. Please direct followups to the group.

    I'll be glad to answer any questions you have along the way.
    bruno.pillet@arturia.com
    New Member
    New Member
    Posts:


    --
    19 Apr 2005 03:50 AM
    thanks peterb it's really usefull
    tozyagcilar
    New Member
    New Member
    Posts:


    --
    25 Apr 2005 11:55 AM
    Hey Peter,

    How about LoLo? Can we use that in instead of LILO? How about grub? Was there a special reason for going with LILO in your previous post?

    Thanks,
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    25 Apr 2005 03:38 PM
    Whoops.
    I meant to say "LoLo" instead of "LiLo"
    miguelgu
    New Member
    New Member
    Posts:


    --
    26 Apr 2005 04:30 AM
    Hi all,
    Talking about MTD driver, does it run in LH79520 platform running kernel 2.4.17-rmk2-lineo5 ? I think it's necessary to implement it to access strataflash intel 16 bus. If someone has experience with this, suggestion will be welcome.
    Thanks in advanced.
    ----------------------
    Miguel Angel Gutiérrez
    miguelangel.gutierrez@gmail.com
    tozyagcilar
    New Member
    New Member
    Posts:


    --
    27 Apr 2005 09:51 AM
    Hello Peter,

    I dont have anything under /proc/mtd, however I have mtdb0,1,2,3 under /dev. I created a jffs2 image of the rootfs on the host but I cannot "mount", nor can I "cat" /dev/mtdbx. I have run MAKEDEV again after reconfiguring the kernel, because initially mount -t did not recognize jffs2. I have added jffs2 support and also mtd support to the kernel, and recompiled/redeployed.

    There are so many files under /maps that define the partitions, how can I be sure which one is being used?

    Currently when I try to "cat jffs2image > /dev/mtdb2" I get the following:

    modprobe: modprobe: Can't locate module block-major-31
    cannot create /dev/mtdb2: no such device or address

    please let me know what you think...

    thanks.
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    27 Apr 2005 10:12 AM
    On the target, cat /proc/devices, and if your MTD is properly put together, you should find the following lines(device number may be different, I'm not sure):

    90 mtd
    31 mtdblock

    This states that you have the MTD char driver (mtd) installed along with its block version (mtdblock). You need these drivers to access the MTD device.

    You can do a "find linux-*/driver/mtd -name '*.o'" to see what kernel MTD files were built, including which map file(if any) was built.

    Also make sure that none of the MTD files are built as modules(grep for MTD in linux-*/.config, and for any that are not commented out, they have to be '=y', not '=n' since if you are trying to use the MTD device as a root filesystem, you need the drivers linked into the kernel since the filesystem has to be mounted before you can load any modules.

    At a *bare* minimum you'll need:

    CONFIG_MTD=y
    CONFIG_MTD_PARTITIONS=y
    CONFIG_MTD_CHAR=y
    CONFIG_MTD_BLOCK=y

    Then you have to have a map for how to access your flash device. I'm not sure if there is one in linux-*/drivers/mtd/map that is specific for the 9520(I don't have the software or any hardware spec handy to know).

    ALso see:
    http://www.linux-mtd.infr...org/doc/general.html
    For more documentation on MTD in Linux and how it hangs together.
    tozyagcilar
    New Member
    New Member
    Posts:


    --
    28 Apr 2005 12:40 PM
    Hello,

    1- There is a file called drivers/mtd/maps/physmap.c. This file is a generic file for specifying the partition table and physical mapping of the flash. The only way to get this file to be included in the kernel image is setting

    CONFIG_MTD_PHYSMAP=y
    CONFIG_MTD_PHYSMAP_START=0x40000000
    CONFIG_MTD_PHYSMAP_LEN=0x20000000
    CONFIG_MTD_PHYSMAP_BUSWIDTH=2

    as you can see the start and length have to be defined also. I have defined these based on the memory map information of the flash supplied on the website(70000125_Rev_B.pdf). Is it safe to assume that this will be same as physical map? If not, how can I figure out the physical location of the flash device?

    2- Do I need the PHYSMAP at all? I think I do, because the kernel needs to know where to look at when passed in the parameter root=/dev/mdblock2

    3- Do I need to rerun MAKEDEV after reconfiguring the kernel since /proc/devices is different?

    I see mtdblock when "cat /proc/devices", but there is no mtd or mtdblock under /dev, there is mtdb0,1,2,3 and mtdc0,2,4,6.

    Thanks.
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    28 Apr 2005 01:00 PM
    Ok, I just had a minute to scan the hardware spec.

    Since its an intel strataflash, you'll want to make sure that:

    CONFIG_MTD_CFI=y
    CONFIG_MTD_CFI_INTELEXT=y

    Are on in your config since the strataflash is a CFI compatible flash device.

    You do need the PHYSMAP entries since physmap.c expects them to figure out what the device looks like and where its found in physical space. Page 21 of the hardware spec shows that the boot flash is located at 0x40000000, so yes the start address looks good. The lenngth looks too large, I think it should be either 0x00800000 or 0x01000000 depending if you have 8Mb or 16Mb of bootflash.

    Before you try to boot out of the flash, run with a rom rootfs (root=/dev/ram) and then poke around in /proc/mtd to see if it finds any flash there.

    You can add to physmap.c a "printk("%s:%d\n, __FUNCTION__, __LINE__);" to dump out whre it gets in its probe for the device.

    I'm not sure about MAKEDEV, since in my system I use a devfs which automatically create shte device nodes on the fly.

    Hopefully this will help you get closer...
    Unfortunately I'm out of country for the next two weeks, so I'll pick this up when I get back(unless someone else answers your questions).

    Good Luck!
    miguelgu
    New Member
    New Member
    Posts:


    --
    26 May 2005 01:48 AM
    Hi,
    Finally MTD works ok with LH79520, but I have a little problem with partitions. I can't manage /dev/mtd1 /dev/mtd2 .... if I use more than 1 partition in flash.
    For example:
    .....
    static struct mtd_partition lpd79520_partitions[] = {
    {
    name: "Initrd",
    size: 0x400000, /* 4MB */
    offset: 0x100000,
    },
    {
    name: "FS",
    size: 0x300000, /* 3MB */
    offset: 0x500000,
    }
    };
    (Total: 8Mbytes, leaving the first megabyte free)
    .......
    When kernel boots:
    .......
    Using buffer write method
    Creating 2 MTD partitions on "LPD79520 flash device":
    0x00100000-0x00500000 : "Initrd"
    mtd: Giving out device 0 to Initrd
    0x00500000-0x00800000 : "FS"
    mtd: Giving out device 1 to FS
    mtd: Init
    ....
    When prompt as root:
    /home/miguel # cat /proc/mtd
    dev: size erasesize name
    mtd0: 00400000 00020000 "Initrd"
    mtd1: 00300000 00020000 "FS"
    /home/miguel #
    ....
    I can erase mtd0, and copy a jffs2 image and mount it using mtdblock0, but with mtd1 all is wrong:
    /home/miguel # flash_erase /dev/mtd1 0 24
    File open error
    /home/miguel #

    /home/miguel # mtd_debug info /dev/mtd0
    mtd.type = MTD_NORFLASH
    mtd.flags = MTD_CAP_NORFLASH
    mtd.size = 4194304 (4M)
    mtd.erasesize = 131072 (128K)
    mtd.oobblock = 0
    mtd.oobsize = 0
    mtd.ecctype = MTD_ECC_NONE
    regions = 0

    /home/miguel # mtd_debug info /dev/mtd1
    mtd.type = MTD_NORFLASH
    mtd.flags = MTD_CAP_NORFLASH
    mtd.size = 4194304 (4M)
    mtd.erasesize = 131072 (128K)
    mtd.oobblock = 0
    mtd.oobsize = 0
    mtd.ecctype = MTD_ECC_NONE
    regions = 0

    mtd0 and mtd1 the same ???? Is incorrect !!!
    Why ? Anything is missing ?
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    26 May 2005 05:41 AM
    >mtd0 and mtd1 the same ???? Is incorrect !!!
    >Why ? Anything is missing ?

    1) If you have a jffs2 filesystem in Nor flash, you don't need the initrd section(unless you want to have a read-only root filesystem). To do this, just change the 'root=/dev/ram' to 'root=/dev/mtdblock0', or whatever your MTD block device is for the FS partition.

    2) I'm not sure why/how the two mtd devices think they are accessing the same MTD portion. What device numbers(major and minor) are /dev/mtd0 and /dev/mtd1? Are they the same? Is CONFIG_MTD_PARTITIONS set to 'y'? If not, then I think its possible for the MTD code to ignore the minor device number and only access the first partition.
    miguelgu
    New Member
    New Member
    Posts:


    --
    26 May 2005 05:56 AM
    I've discovered my mistake (fatal) with mtd0 and mtd1: the minor number. Instead 0, 2, 4 I've used 0,1,2,3. After fixed it works fine.
    The first partition will be initrd, to use 16MB of SDRAM as filesystem (RAMDISK), and second partition as jffs2, mounting it after boot the system, using as support for useful information non-volatile. The most important reason to do that is the cycle-life of flash. Mounting the root as jffs2, the life of flash will be shorter. Tell me any opinion.
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    26 May 2005 07:00 AM
    >I've discovered my mistake (fatal) with mtd0 and mtd1: the minor number. Instead 0, 2, 4 >I've used 0,1,2,3. After fixed it works fine.

    Good to hear.

    >The first partition will be initrd, to use 16MB of SDRAM as filesystem (RAMDISK), and >second partition as jffs2, mounting it after boot the system, using as support for useful >information non-volatile. The most important reason to do that is the cycle-life of flash. >Mounting the root as jffs2, the life of flash will be shorter. Tell me any opinion.

    Why do you think the life of flash will be shorter if the root is jffs2 instead of a RAMDISK? Are there files that you plan to modify, quite frequently that are temporary? You could trying creating/mounting a temporary file system(such as /tmp) so temporary files don't get written to flash.

    mount tmpfs /tmpfs -t tmpfs -o size=500k

    will mount onto /tmpfs a temporary filesystem that is 500K in size. this filesystem is RAM based and as such is volatile. That is if CONFIG_TMPFS is set to 'y'
    tozyagcilar
    New Member
    New Member
    Posts:


    --
    26 May 2005 02:57 PM
    We are trying to copy the jffs2 image of the root filesystem to the on-board flash, but we are getting an errors regarding the VPP.

    After a little investigation we figured out that there is no reference set_vpp function in physmap.c, and the armflash_set_vpp in integrator_flash.c does not do anything for CONFIG_ARCH_P720T. How does the programming voltage get set/cleared when using physmap? Is there anything additional to be done to physmap.c other than specifying the partitions, or to integrator_flash.c?

    I am mounting the partition for the root filesystem without any mask_flags so I am assuming that I am able to mount it read/write.

    LoLo is able to write to the flash, so I must be doing something wrong. Not sure what. Any help is appreciated...

    T.
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    26 May 2005 03:27 PM
    >After a little investigation we figured out that there is no reference set_vpp function in >physmap.c, and the armflash_set_vpp in integrator_flash.c does not do anything for >CONFIG_ARCH_P720T. How does the programming voltage get set/cleared when using >physmap? Is there anything additional to be done to physmap.c other than specifying the >partitions, or to integrator_flash.c?

    I don't have the code in front of me, but I see from some of the other map files in linux-2.4.26 that the function(int drivers/mtd/maps/*.c):

    void XXX_set_vpp(struct map_info *map, int vpp);

    Is what manipulates VPP, and that in the map_info struct type that is passed to do_map_probe, there is a function pointer 'set_vpp' which should be initialized to your vpp function. Look at some of the other map files in drivers/mtd/map/*.c to see how this is done.
    tozyagcilar
    New Member
    New Member
    Posts:


    --
    27 May 2005 12:19 PM
    Other files under maps directory are for different platforms. On this board (LH79520-10) there is a CPLD that controls the VPP enable. This CPLD to us, is a black box. So I don't think we can figure out how to write the set_vpp function ourselves. Is the code for LoLo freely available? It should be obvious what to do looking at that code.

    Also, the LCD seems to be going to sleep, becoming unresponsive after a while after startup (like around 15-20mins). Any idea why this might be happening?

    Thanks.

    T.
    miguelgu
    New Member
    New Member
    Posts:


    --
    30 May 2005 02:39 AM
    Hi everybody.
    The vpp signal is not strictly necessary, just putting it to 1 logic is necessary and forget this pin of CPLD.
    I've implemented a map for LPD79520, if anyone is interested I'll send patch and mini-howto if necessary. It's working: A jffs2 filesystem to boot from.

    Miguel Angel Gutiérrez
    GCT Iberica.
    miguelangel.gutierrez@gmail.com
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    01 Jun 2005 12:00 PM
    All Card Engines have an I/O controller spec written that explains the functionality of the CPLD. In this instance, you can write to the 'Flash register' which has a bit (bit 0) to set the programming mode for Flash. If set to '1', the FlashVPEN is set high and the chips can be programmed. This register also contains the status signal from the Flash chip (bit 1).

    http://www.logicpd.com/downloads/26
    (Section 2.1.9)

    Thanks,
    -Mike Aanenson
    You are not authorized to post a reply.