Application on QSPI Flash running Linux

[busy_bri]

Hi All,

I'm trying to store an application on a QSPI flash Partition but I feel like I'm missing an obvious detail.

My flash device is 16MB and Contains the following:

Partition 0: “Boot” FSBL, (U-Boot) and bitstream          (0x00000000 – 0x00500000

Partition 1: “Bootenv” Stored environment of U-Boot (0x00500000 – 0x00520000)

Partition 2: “Kernel” Linux kernel                                    (0x00520000 – 0x00FA0000)

Partition 3: “App” My linux application                           (0x00FA0000 – 0x00FFFFFF)

Using XSDK Created a Bif and placed the elf file of my application in partition 3. The problem I have is when I try to dd the file from the /dev/mtd3 directory only a section of the elf is correct (compared data). I thought maybe its some sort of compression issue or bad sector.

Is it even possible to keep Linux Applications on QSPI and run them after Linux boots?

The App is in the Flash because integrating it with the kernel is not ideal. (petalinux-create -t apps method)

Kind Regards,

Brion

[rfs613 · Accepted solution]

The most likely explanation is that you are not erasing the flash prior to writing to it, or only part of it is being erased. Another possibility is that Petalinux is doing some operation on the ELF file (such as objdump to raw binary) when processing your .BIF commands.

Note that storing a single application on a raw /dev/mtd device is not typical. It can be done, the MTD layer does not care, but you will have to manage erasing and writing (and wear leveling, compression, redundancy, etc) yourself.

The more typical way to use the /dev/mtd3 partition is to place a filesystem there - one that is designed for flash, for example JFFS2 or UBIFS. That way it can hold multiple files (programs, data, etc), the data is compressed/decompressed automatically, etc. Often the whole root filesystem is placed in there, rather than the Petalinux default of using a ramdisk.

[busy_bri]

Thanks rfs613,

It turns out the Bootgen doesn't leave ELF files alone even though it's set as Datafile. It split the ELF file into 2 separate files MY_APP.elf.0 and MY_APP.elf.1 :

           -- Dump of Binary Image ----
           00000000 Len: 000008a0 Res: 00000000 "BootHeader"
           000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable"
           00000900 Len: 00000024 Res: 00000000 "ImageHeader zynq_fsbl.elf"
           00000940 Len: 0000002c Res: 00000000 "ImageHeader design_1_wrapper.bit"
           00000980 Len: 00000020 Res: 00000000 "ImageHeader u-boot.elf"
           000009c0 Len: 00000020 Res: 00000000 "ImageHeader image.ub"
           00000a00 Len: 00000028 Res: 00000280 "ImageHeader MY_APP.elf"
           00000c80 Len: 00000040 Res: 00000000 "PartitionHeader zynq_fsbl.elf.0"
           00000cc0 Len: 00000040 Res: 00000000 "PartitionHeader design_1_wrapper.bit.0"
           00000d00 Len: 00000040 Res: 00000000 "PartitionHeader u-boot.elf.0"
           00000d40 Len: 00000040 Res: 00000000 "PartitionHeader image.ub.0"
           00000d80 Len: 00000040 Res: 00000000 "PartitionHeader MY_APP.elf.0"
           00000dc0 Len: 00000040 Res: 00000000 "PartitionHeader MY_APP.elf.1"
           00000e00 Len: 00000040 Res: 00000900 "PartitionHeader Null"
           00001700 Len: 00018008 Res: 00000000 "zynq_fsbl.elf.0"
           00019740 Len: 001fcba0 Res: 00000000 "design_1_wrapper.bit.0"
           00216300 Len: 00060ee0 Res: 00000000 "u-boot.elf.0"
           00520000 Len: 008d61c0 Res: 00a80000 "image.ub.0"
           00fa0000 Len: 00013d14 Res: 00050000 "MY_APP.elf.0"
           00fb3d40 Len: 0000027c Res: 00000000 "MY_APP.elf.1"

According to UG821 (p.g 58), It seems to also removes headers and symbols from ELF files. I've had to rename the ELF to a BIN (I may compress it to a GZ file) for Bootgen to leave it alone.

           00000000 Len: 000008a0 Res: 00000000 "BootHeader"
           000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable"
           00000900 Len: 00000024 Res: 00000000 "ImageHeader zynq_fsbl.elf"
           00000940 Len: 0000002c Res: 00000000 "ImageHeader design_1_wrapper.bit"
           00000980 Len: 00000020 Res: 00000000 "ImageHeader u-boot.elf"
           000009c0 Len: 00000020 Res: 00000000 "ImageHeader image.ub"
           00000a00 Len: 00000028 Res: 00000280 "ImageHeader MY_APP.bin"
           00000c80 Len: 00000040 Res: 00000000 "PartitionHeader zynq_fsbl.elf.0"
           00000cc0 Len: 00000040 Res: 00000000 "PartitionHeader design_1_wrapper.bit.0"
           00000d00 Len: 00000040 Res: 00000000 "PartitionHeader u-boot.elf.0"
           00000d40 Len: 00000040 Res: 00000000 "PartitionHeader image.ub.0"
           00000d80 Len: 00000040 Res: 00000000 "PartitionHeader MY_APP.bin.0"
           00000dc0 Len: 00000040 Res: 00000940 "PartitionHeader Null"
           00001700 Len: 00018008 Res: 00000000 "zynq_fsbl.elf.0"
           00019740 Len: 001fcba0 Res: 00000000 "design_1_wrapper.bit.0"
           00216300 Len: 00060ee0 Res: 00000000 "u-boot.elf.0"
           00520000 Len: 008d61c0 Res: 00a80000 "image.ub.0"
           00fa0000 Len: 00044924 Res: 00050000 "MY_APP.bin.0"

Indeed this is not typical but incorporating the Application in the rootfs doesn't suit our design at the moment but we may use the method the typical method eventually.

Thanks again.