How to program zybo boot Image to QSPI Flash from kernel user space?

[diya-]

Hi,

I have recently purchased ZYBO KIT and trying to re-program u-boot ,kernel, ramdisk image from kernel user space.

I have gone through the below link and downloaded ramdisk image (arm_ramdisk.image.gz)

http://www.wiki.xilinx.com/Build+and+Modify+a+Rootfs

After extracting the arm_ramdisk.image.gz  zip file, I found a script file (update_qspi.sh).

Which program u-boot, Linux, and ramdisk image to QSPI flash.

 

In this script file (update_qspi.sh) I found that, the below command is used to write the U-boot, Linux, Ramdisk image to QSPI flash

 

flashcp -v $path/qspi-u-boot.bin /dev/mtd13 // for U-Boot image

 

flashcp -v $path/qspi-u-boot.bin /dev/mtd15 // for Linux image

 

flashcp -v $path/qspi-u-boot.bin /dev/mtd18 // for Ramdisk image

 

I couldn't able to find the programmed location of images in qspi and also details about mtd 13,mtd15 and mtd18.

 

I want to change the flash program address of Linux and ramdisk image.

 

Do i need to create specific entry for u-boot, Linux and ramdisk image in user space.

 

Can any one guide me on how to specify the flash address and program from user space.

 

[jpeyron]

Hi @diya-,

I am not an experience embedded linux engineer. I have reached out to my co-workers to see if they have any more input for you.

thank you,

Jon

[diya-]

Hi jpeyron,

     Am waiting for the input from your engineers.

[Ciprian]

It is unclear to me what you mean by: "I want to change the flash program address of Linux and ramdisk image." Do you want to load the ramdisk and the kernel to a specific location in the QSPI or do you want to change where the ramdisk is loaded in the DDR memory on booting, because as far as I know when the kernel boots it loads the content of the QSPI (kernel and ramdisk) in to a specific location in the DDR.

[diya-]

Hi,

 

On 6/7/2017 at 6:14 PM, Ciprian said:

Do you want to load the ramdisk and the kernel to a specific location in the QSPI

Yes,

http://www.wiki.xilinx.com/Build+and+Modify+a+Rootfs

I downloaded ramdisk.gz from the above link and it has script "update_qspi.sh" which use flashcp to flash the kernel and file system image to qspi.

flashcp -v $path/qspi-u-boot.bin /dev/mtd13

I am not familiar to what address does /dev/mtd13 denote and why images are specifically flashed at this /dev/mtd* entries.

Can you please provide information about this /dev/mtd* mapping. Such that i can view the mapping and flash the kernel and file system at our desired address.

Please find the script attached,

 

update_qspi.sh

[diya-]

Hi...

       I have successfully created mtd partitions and flashed images flashcp command and verified it successfully.

        QSPI part used in ZYBO kit is S25FL128S and am able to achieve mtd partition after adding compatible qspi type as "s25fl129p1" in device tree. 

        In attached QSPI cypress datasheet they have mentioned address mapping with respective to Top and Bottom Sectors as below,

     

                                S25FL128S Sector and Memory Address Map, Bottom 4-kbyte Sectors

                                S25FL128S Sector and Memory Address Map, Top 4-kbyte Sectors

                                S25FL128S Sector and Memory Address Map, Uniform 256-kbyte Sectors 

         Could you please tell us which sector ( TOP or BOTTOM ) to select and on what basis we have to select sector type ..?

        This would help us to know memory map of our 32 MB  QSPI flash in our custom design.

         I have attached the datasheet link here. http://www.cypress.com/file/177966/download   (page 44 )

              

[jpeyron]

Hi @diya-,

Unfortunately, I would not have any helpful input for your question.  I have reached out to my co-workers to see if they have any input for you.

thank you,

Jon

[diya-]

hi @jpeyron ,

Have you found the sector type ( TOP or BOTTOM ) for QSPI memory map for our custom designed zynq board as i mentioned in my previous post ?

Could you please provide me a solution..? Its kind of urgent...

thank you,

diya-

[D@n]

@diya-,

Be nice to the guy ... he's got no clue how to answer your question.  Further, he's not getting paid to solve your problem either.  He's getting paid to make certain your hardware works.  In this case, it appears to work.

And ... while I understand what the top and bottom parts of flash memory are, what I can't understand is how or why you would want to use them in a Linux context.  No application I've known of my own has needed them.

As I've used mtd devices (and other similar devices) in the past, /dev/mtd1? usually references your first /dev/mtd* device.  /dev/mtd11 references the first partition on that device.  You'll need to dig further into the Linux kernel, though, and particularly into the mtd device driver to get more information on that naming scheme.  It's a Linux naming scheme, following a similar UNIX naming scheme.  I've found this reference to be very good at helping me understand these types of questions, but you may also find you need to look in your kernel's ./Documentation directory for information on the mtd device.

Indeed, you might consider opening your /dev/mtd1 device up in a partition editor.  It might tell you more of what's going on.

Dan

[diya-]

On 7/25/2017 at 4:48 PM, diya- said:

...

 

On 7/25/2017 at 5:07 PM, D@n said:

Be nice to the guy ... he's got no clue how to answer your question.  Further, he's not getting paid to solve your problem either.  He's getting paid to make certain your hardware works.  In this case, it appears to work.

I apologize .I dint really mean to question in harsh way. Please don't mind.

 

On 7/25/2017 at 5:07 PM, D@n said:

And ... while I understand what the top and bottom parts of flash memory are, what I can't understand is how or why you would want to use them in a Linux context.  No application I've known of my own has needed them.

Yes , You are wright. our application doesn't have dependency to know the top or bottom sector. But we need to provide sector address mapping to our customer and i am confused of  term top and bottom sector that is specified in the flash datasheet even though both have same start(0x0) and end address (00FFFFFF). I am using flash part S25FL128S and how to know whether it follow top or bottom sector.

 

On 7/25/2017 at 5:07 PM, D@n said:

As I've used mtd devices (and other similar devices) in the past, /dev/mtd1? usually references your first /dev/mtd* device.  /dev/mtd11 references the first partition on that device.  You'll need to dig further into the Linux kernel, though, and particularly into the mtd device driver to get more information on that naming scheme.  It's a Linux naming scheme, following a similar UNIX naming scheme.  I've found this reference to be very good at helping me understand these types of questions, but you may also find you need to look in your kernel's ./Documentation directory for information on the mtd device

In our board, mtd1 refers to first partition and in which u-boot resides.We framed device tree with qspi structure like shown below and then we were able to detect mtd0,1,2,3 partition in /dev and successfully able to boot the images.But you have mentioned /dev/mtd11 references the first partition and there is no such like /mtd11 present in our dev entry. Is this specific to your board or in generic /mtd11 references first partition. Can you tell us whether the procedure we are following to create mtd partition is correct ?

 

qspi: spi@e000d000 {
                        clock-names = "ref_clk", "pclk";
                        clocks = <&clkc 10>, <&clkc 43>;
                        compatible = "xlnx,zynq-qspi-1.0";
                        status = "disabled";
                        interrupt-parent = <&intc>;
                        interrupts = <0 19 4>;
                        reg = <0xe000d000 0x1000>;
                        #address-cells = <1>;
                        #size-cells = <0>;
                        flash@0 {
                                        compatible = "s25fl129p1";
                                        reg = <0x0>;
                                        spi-tx-bus-width = <1>;
                                        spi-rx-bus-width = <4>;
                                        spi-max-frequency = <50000000>;
                                        #address-cells = <1>;
                                        #size-cells = <1>;
                                        partition@qspi-fsbl-uboot {
                                                label = "qspi-fsbl-uboot";
                                                reg = <0x0 0x600000>;
                                        };
                                        partition@qspi-linux {
                                                label = "qspi-linux";
                                                reg = <0x600000 0x400000>;
                                        };
                                        partition@qspi-device-tree {
                                                label = "qspi-device-tree";
                                                reg = <0xa00000 0x20000>;
                                        };
                                        partition@qspi-rootfs {
                                                label = "qspi-rootfs";
                                                reg = <0xa30000 0x520000>;
                                        };
                                };
                };

 

[jpeyron]

Hi @diya-,

Unfortunately, my co-workers have not had any additional input for your questions. Have you tried reaching out to Xilinx or Cypress to see if they had any additional input for you?  

thank you,

Jon