logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.
Question

IGEP v2 RC6 NAND BOOT

posted in IGEPv2
Monday, February 08 2016, 05:46 PM
Grat
Grat
Offline
0
Hello,

is there a way to get my IGEP v2 RC6 boot from nand without having a jffs2 partition? Can the igep-x-loader (which seems to be the only way to access the NAND) be configured to fetch and run u-boot.img from a nand address (like the old x-loader)?

Thank you,
Alberto
Responses (8)
  • Accepted Answer

    Tuesday, February 09 2016, 11:50 AM - #permalink
    0
    Hi Grat,

    I answer your questions below:

    is there a way to get my IGEP v2 RC6 boot from nand without having a jffs2 partition?

    Yes, you can use UBIFS partitions. There is an example in: http://labs.isee.biz/index.php/IGEPv2_Ubuntu_Distro_flash

    Take a look at ISEE_README file to configure igep.ini properly.

    Can the igep-x-loader (which seems to be the only way to access the NAND) be configured to fetch and run u-boot.img from a nand address (like the old x-loader)?

    Yes, but IGEPv2 has support for U-boot too.

    Cheers!
    The reply is currently minimized Show
  • Accepted Answer

    Grat
    Grat
    Offline
    Tuesday, February 09 2016, 12:17 PM - #permalink
    0
    Hello and thanks for the answer.

    Yes, I can use UBI, but it seems that igep-x-loader needs a boot jffs2 partition to locate and load the IGEP.INI file.
    Is there a way to tell igep-x-loader to forget about the IGEP.INI file and go get u-boot.img from a NAND (raw) address?

    Thanks,
    Alberto
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, February 10 2016, 10:28 AM - #permalink
    0
    Hi Alberto,

    Is there a way to tell igep-x-loader to forget about the IGEP.INI file and go get u-boot.img from a NAND (raw) address?

    igep.ini and zImage (or another bootable binary) are stored with jffs2 file system to preserve data integrity and avoid bad memory block issues. So it is not recommended storage your binaries in raw mode. Raw mode schema is only recommended to bootup your system more quickly but software residing inside the flash can be damage more easily.

    A solution could be merge igep.ini file into igep-x-loader source code, allow igep-xloader to read binaries in raw mode and copy zImage or u-boot.img to the second partition (mtd1) using nandwrite tool, but you should need to modify igep-x-loader source code.

    My recommendation is use u-boot instead igep-xloader: http://labs.isee.biz/index.php/U-Boot_Mainline_Series.

    Cheers!
    The reply is currently minimized Show
  • Accepted Answer

    Grat
    Grat
    Offline
    Wednesday, February 10 2016, 09:54 PM - #permalink
    0
    OK, thanks. I'll try the u-boot way, assuming that's allowed to flash MLO starting from 0x00000000 and u-boot.img from 0x00080000 (which would be the beginning of the second partition).

    Cheers,
    Alberto
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 11 2016, 09:42 AM - #permalink
    0
    Hi Alberto,

    I suggest the following partitions into internal flash memory:
    mtd0: 00080000 00020000 "SPL"
    mtd1: 001e0000 00020000 "U-Boot"
    mtd2: 00020000 00020000 "Environment"
    mtd3: 00500000 00020000 "Kernel"
    mtd4: 1f880000 00020000 "Filesystem"

    From SD card bootup, use writeloader tool to copy MLO and u-boot.img:
    ./writeloader -i MLO -o /dev/mtd0
    ./writeloader -i u-boot.img -o /dev/mtd1

    Cheers!
    The reply is currently minimized Show
  • Accepted Answer

    Grat
    Grat
    Offline
    Thursday, February 11 2016, 05:33 PM - #permalink
    0
    Hello,

    I'm not sure I understand the partition table you have written in your email. Is the first column the offset and the second the size in bytes?
    One more question: why shall I use writeloader and not the u-boot (which I would temporarily set up via a MMC boot) nand write command?

    What I'd like to do is:
    - bootstrap with MMC and have u-boot running
    - get the MLO and u-boot.img binaries via tftpboot
    - put them into the flash using nand erase and nand write
    - get rid of the MMC and boot off the flash

    Thanks again,
    Alberto
    The reply is currently minimized Show
  • Accepted Answer

    Grat
    Grat
    Offline
    Friday, February 12 2016, 05:59 PM - #permalink
    0
    Hello,

    finally I stored MLO and u-boot in the nand and now I have an U-boot prompt.
    One more problem: when I try to boot a kernel (for now just with tftpboot) I can't see the nand partitions, nor the omap2-nand line in the console boot messages.
    Do you know which particular driver should I enable? I am using Linux 3.14.
    Is there any particular entry in the devicetree that enables the nand probing?

    Thanks,
    Alberto
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 15 2016, 12:10 PM - #permalink
    0
    Hi Alberto,

    I'm not sure I understand the partition table you have written in your email. Is the first column the offset and the second the size in bytes?
    Is there any particular entry in the devicetree that enables the nand probing?

    My fault, the last NAND partition table was wrong. The next structure, comes from 3.17.y Kernel (pushed to mainline), is correct:
    partition@0 {
    label = "SPL";
    reg = <0 0x100000>;
    };
    partition@80000 {
    label = "U-Boot";
    reg = <0x100000 0x180000>;
    };
    partition@1c0000 {
    label = "Environment";
    reg = <0x280000 0x100000>;
    };
    partition@280000 {
    label = "Kernel";
    reg = <0x380000 0x300000>;
    };
    partition@780000 {
    label = "Filesystem";
    reg = <0x680000 0x1f980000>;
    };

    Where reg = <"memory offset" "memory size">;

    Do you know which particular driver should I enable? I am using Linux 3.14.

    I suggest you to follow the next tutorial and use Kernel 3.17.y instead 3.15 or 3.14

    Cheers!
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat