How do you make a program that runs on the iRAM?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How do you make a program that runs on the iRAM?

Jump to solution
3,742 Views
daisukekitsunai
Contributor I

hi

I have been developing custom i.MX53 board based on the QSB.

Now, I will need a memory test program to test the entire DRAM.

Since the entire DRAM test that program, the program can not be placed on the area data DRAM.

I need to write programs that can run on iRAM to output the data from the UART can be controlled by the DRAM.

I'm referring to the source file of u-boot and now OBDS.

However, there is no chance of completion.

Do not you know other information which may be helpful anyone?

Labels (1)
0 Kudos
1 Solution
2,250 Views
JorgeRama_rezRi
NXP Employee
NXP Employee

Hi,

Sorry, I should have attached the whole project from the beginning. I'm attaching the folder with all the files now. Please note that I have renamed DDR_test.c to main.c so the project is correctly compiled, but it's the same file. As

View solution in original post

0 Kudos
19 Replies
2,250 Views
JerryFan
NXP Employee
NXP Employee

The DDR_Test.zip can be a good beginning of your the DDR stress test tool, and you must add some more stressful algorithms.   To tell which tool is more stressful, you can run the test with DDR frequency increasing step by step, and record the highest frequency on which the test failed, and the tool which has the lower failure-frequency is more streesfull.

If you can find a algorithms much more stressful than the ones within DDR Stress Tester tool for i.MX53, please let me know.

0 Kudos
2,250 Views
JerryFan
NXP Employee
NXP Employee

I had read the DDR_test.c, I am afraid the algorithm for memory testing within this file is not stressful enough for the DDR stability test. OMO, the algorithms within DDR stress tester tool are much stressful, and basically, the DDR stress tester implement the several SSN test with different type, please google "SSN memory" for detail.

0 Kudos
2,250 Views
JorgeRama_rezRi
NXP Employee
NXP Employee

Hi,

JTAG stores your test program in iRAM, this is the only way I know to run SW from this location. The only thing you need to do is to set up your scatter file with the iRAM memory address. You'll need the JTAG port of the QSB available and a debugger like the Real View ICE. I'm attaching a simple test code for the DDR, I hope this is useful for you.

Best regards.

Jorge.

0 Kudos
2,250 Views
daisukekitsunai
Contributor I

Thank you.

It is the source file that contains all the features that I have been looking for!

If based on this source, I think for the memory test program creation is not difficult.

I have one question.

This source file I have been include func.h, where is this file?

I have not been able to find.

0 Kudos
2,251 Views
JorgeRama_rezRi
NXP Employee
NXP Employee

Hi,

Sorry, I should have attached the whole project from the beginning. I'm attaching the folder with all the files now. Please note that I have renamed DDR_test.c to main.c so the project is correctly compiled, but it's the same file. As

0 Kudos
2,250 Views
VladanJovanovic
NXP Employee
NXP Employee

As you're planning to write app to test DDR, have you seen DDR Stress Tester tool for i.MX53?

You can download it here (under "Lab and Test Software"):

i.MX535 Product Summary Page

2,250 Views
daisukekitsunai
Contributor I

The program may be tried once.

I gave up the use of the program for the following reasons.

1, I think not test the entire memory from one time per test.

2, Because there was no description of the algorithm for memory testing, I could not be used to assess the quality of their products.

0 Kudos
2,250 Views
Yuri
NXP Employee
NXP Employee

You may use the enclosed example (say, how to configure GPIO  on i.MX53 QSB).

Application image may be loaded and run on the QSB using both :

- ATK tool (please look at .jpg(s)) ;

- single UART loader (please look at "mx53_com_load.bat").

Note internal serial (UART / USB) boot mode of the i.MX53 is used here.

2,250 Views
RSmith
Contributor I

Hey Yuri

I downloaded your zip file and tried to run it just to see it download via the serial port and I could never get to "catch" and download via the ROM monitor with the batch file. (I'm on a ARD so it won't actually run.) 

Question? Null modem or cross over cable? And what about CTS the manual said the host controls that so I'm guessing you tied it (high/low) on the cable? Finally I did not see an offset for the IVT/BS in the crt.s file like the NOR/NAND (I have both those working but need a fall back boot mode so I want to create a Serial Download image to re-flash NOR/NAND boot images.)

Finally you have a mysterious value in the IVT/BS data (0xF8002000??) what's that value for because the iRAM looks to start at 0xF8006000. So I'm guess that's somewhere in the ROM monitor RAM space.

CRT.S

/* Image Vector Table (IVT)   - should be placed before main image */

ivt_header : .byte 0xD1

                 .byte 0x00

                 .byte 0x20

                 .byte 0x40

app_code_jump_vector : .word  ResetHandler

                                    .word 0

dcd_ptr :                       .word 0

boot_data_addr :           .word boot_data

self_ptr :                       .word ivt_header

                                    .word 0

                                   .word 0

boot_data :                   .word 0xF8002000

image_len :                  .word 0x10000   /*  64 KB  app size */

Thanks Rx

0 Kudos
2,250 Views
Yuri
NXP Employee
NXP Employee

1.

> Null modem or cross over cable?

I am slightly confused, since - my opinion - null modem is just cross cable : TX is tied to RX.
For i.MX53 QSB we should use  male-female (pin-to-pin) cable.   


2.
> I did not see an offset for the IVT/BS in the crt.s file ...

For (internal) UART loader the header should be the first in stream.
This may be considered as zero offset.

3.
> ... mysterious value in the IVT/BS data (0xF8002000??) what's that value for because the iRAM
> looks to start at 0xF8006000

Correct - it should be 0xF8006000. Earlier I used start address at 0xF8002000.


4.
Please check if internal serial UART / USB boot mode is selected. 

0 Kudos
2,250 Views
RSmith
Contributor I

Thanks Yuri

1.

Null modem or cross over cable?

>>I am slightly confused, since - my opinion - null modem is just cross

cable : TX is tied to RX.

>>For i.MX53 QSB we should use male-female (pin-to-pin) cable.

Thanks, I don't have a RS232 on the back of my PC so I'm using a USB to

RS232 cabled (9pin) to connect to the board and it works fine for U-Boot

and Linux but does not work for the MX_Serial.exe program so I wanted to

know the pin out on your cable just in case some other pins were cross or

tied high or low.

Also do you have the source for the MX_Serial.exe program?

Thanks

Rx.

0 Kudos
2,250 Views
Yuri
NXP Employee
NXP Employee

Please try the enclosed.

0 Kudos
2,250 Views
AndreyPismennyy
Contributor II

Dear Yuri,

I'm in a process of serial downloading of iMX-53 micro via UART port. I study your examples of target code and UART downloader and have some questions.

1.     As I understood, the IVT header has to be placed at the head point of program image. But I did'n found the IVT in *.map file of target software, it seems to be removed by linker, because it has no any external references. The program image is downloading from 0xF8006000, which is the interrupt vector table address.

2.     From the UART loader source file, I found that You download the program image by several blocks using the 0x00 file type identifier, which differ from identifiers, listed in 7.8.3.5 item. Then You complete the download procedure with writting of zero-length block at RESET address as an 'application' type file and get status as 'completed' command. Is it enough to perform firmware startup from downloded image? It seems to be useful, because allows program downloading at different memory areas (e.g. to place interrupt vectors and routines in iRAM while other program locates in DDR).

If more suitable, we can correspond in russian via e-mail pan@infotek.ru

0 Kudos
2,250 Views
Yuri
NXP Employee
NXP Employee

Please look at my comments below :

1.

> As I understood, the IVT header has to be placed at the head point of program image.

Correct,

UART boot loader expects the IVT data first in boot stream in order to define such parameters

as application image length (image_len), address to load (boot_data_addr), start address

(app_code_jump_vector).

1.1.

> But I did'n found the IVT in *.map file of target software, it seems to be removed by linker,

> because it has no any external references.

Yes, I think it is enough to define global label in IVT to get it in the map. But again, the IVT addresses

for UART bootloader are not defined ; as mentioned, the IVT table should be first in the stream.

In contrast, we have predefined IVT locations for NAND or SD boot.  And this is a prerogative of

NAND / SD bootloader to read proper block of data first in order to define IVT parameters.

2.

As for UART loader sources – it is adaptation of i.MX21 loader from redboot package, and, strictly

speaking, I am not fully sure, that all is OK for i.MX53. As usually, the debugging was stopped after

first successful loading. So, fill free to modify and develop it as needed.   

0 Kudos
2,249 Views
AndreyPismennyy
Contributor II

Dear Yuri,

now I have the first successfull experience of iMX35 downloading via

UART serial interface.

Generally speaking, its is very close to Your recomendations, below

there are some issues, which I wish to note specially.

1. The DDR was configured with DCD settings, which were performed by

series of MemoryWrite commands. It was more convenient to me to make a

separate assembler file, containing DCD table only (with corrected

endian format, MSB first), which was built in separated *.hex file. At

iMX downloading startup, this file is opening and then read row-by-row

with standard fgets(*file) command. DCD configuration completes at the

standard end of INTEL hex file.

2. To provide program image downloading in different memory areas (e.g.

I have interrupt routines in iRAM to improve the productivity), the

other INTEL hex file is also suitable, The downloading procedure is also

performing row-by-row with WriteFile commands, containing the address,

taken from hex file string (accounting the segment address from special

hex strings), the bytes counter is the number of bytes (not ASCII

chars!) in hex string and file type is unspecified (I used simple 0x00).

When whole file was donloaded, the WriteFile command with program image

start address, zero length and filetype=0xAA (application) was issued

and followed by GetStatus command to start the execution.

3. The IVT was placed right before the program image and was created in

assembler startup file with special section, linked to Start_of_RAM address.

Thank You for assistance,

Andrey.

06.03.2013 5:34, Yuri Muhin написал:

>

Freescale Community <https://community.freescale.com/index.jspa>

<https://community.freescale.com/index.jspa>

>

How do you make a program that runs on the iRAM?

created by Yuri Muhin <https://community.freescale.com/people/Yuri> in

/i.MX Community/ - View the full discussion

<https://community.freescale.com/message/318319#318319>

0 Kudos
2,249 Views
RSmith
Contributor I

Thanks Yuri,

For the Software.

I believe my problem is the HW difference between the QSB and the ARD (Auto/DDR3) board. The RM (7.8.2.1) said they have to be wired up (UART1) TX->CSIO_DAT10.alt2 & RX->CSIO_DAT11.alt2 and the ARD board isn't wired that way so the ROM monitor never see the data coming in on  UART1. (Other Uarts are not accessible on the ARD with a connector. So those are not an option either.)

If somebody comes up with a different explanation or suggestion I'd like to hear it? 

0 Kudos
2,250 Views
Yuri
NXP Employee
NXP Employee

You are right – boot ROM Serial Downloader  can work only with
the UART configurations, mentioned in Table 7-43 (UART IOMUX Pin
Configuration) of the i.MX53 Reference Manual.

For the SABRE AI design the next UART1 pins are used :

UART1_TX(PATA_DIOW).
UART1_RX(PATA_DMACK).

 
This configuration is not supported by boot ROM.
But UART2 may be used, please try it  :
UART2_RX(PATA_BUFFER_EN).
UART2_TX(PATA_DMARQ).

0 Kudos
2,250 Views
RSmith
Contributor I

Thanks,

On Fri, Dec 14, 2012 at 12:59 AM, Yuri Muhin

0 Kudos
2,250 Views
daisukekitsunai
Contributor I

Thank you for your source file.

I would like to create a memory test program using this file.

Thank you very much.

0 Kudos