Deploying SDK 1.3.2

Document created by Paul Genua Employee on May 1, 2013Last modified by Paul Genua Employee on May 11, 2013
Version 1Show Document
  • View in full screen mode

In a previous document, I went through the basic steps of building SDK 1.3.2 for the first time. Now I'm ready to deploy the images onto my target, a P3041DS system.

 

Fortunately my P3041 already has a U-boot and linux install on it. So I can just try and update the SDK from within U-boot.

 

I boot up my trusty terminal - I use putty, and connect to my local COM port at 115200 baudrate. My Ubuntu server already has a tftp server installed, and I link my images over from the SDK build/deploy/images directory over to the /tftpboot directory.

 

The QorIQ_SDK_Infocenter.pdf document within the install has information on the flash bank usage for the current SDK. Make sure you use the document and flash map from the current SDK, as things change. I ended up with a system that didn't boot when I used the older location for the fman uCode (from SDK 1.x) on the SDK 1.3.2 system. Here is a table from the document that shows the flash map for a couple of the QorIQ DS system.

flash_layout.png

It's important to note here that this covers the NOR flash - which is what I'm currently using. You may want to experiment with using NAND or SPI based flash instead - but for my purposes I'm going to re-image NOR flash.

 

The NOR on these development systems is banked, meaning that the most significant address line is tied to a DIP switch. So I can have multiple images in Flash at one time, and switch between them (especially helpful when I mistakenly corrupt one).

 

I'm currently in bank0 (which is the "current bank" in the table above). From this, I see that the addresses I should be interested in are located at:

NameAddress
rcw0xe8000000
Linux.uImage0xe8020000
uBoot

0xeff800000

fman uCode0xeff40000
device tree0xe8800000
linux rootfs0xe9300000

 

To verify that this is correct, I can dump out my RCW:

rcw.png

 

And I can also dump out my current U-boot (which should always start with an ASCII header identifying it):

u-boot.png

 

at this point I can start updating the images directly from my TFTP server. I have my tftp server already defined via the U-boot environment serverip, so I just tftp the U-boot image to a randomly picked address in RAM of 0x100000.

ubot_tftp.png

 

The transfer went ok, so I can burn it into flash now. I will first erase the flash starting at 0xeff80000. Since U-boot is 0x80000 size, I'll erase from 0xeff80000 for size 0x80000.

protected.png

Apparently my sectors were protected. So I need to unprotect first, then erase again.

erased.png

And by reading the flash, I verify that it has been erased (erased NOR always reads back all 0xF's)

 

So, now I can burn the flash:

u-boot_copied.png

I use a binary copy. And then verify that the image was written correctly.

 

Then we go through the same technique with the other images. I'll burn the fman ucode as well:

ucode.png

 

Then for the actual images and dtb, you have an option of burning them, but I'll tftp them instead. For this I created a U-boot environment variable called ramboot, and point the image names to the paths on my server:

env.png

 

At this point I can save the environment to flash via a saveenv command in U-boot. I'll re-boot into the new U-boot to make sure it works (if it doesn't for some reason, I can jump back to a different U-boot I had previously burned in the alternate bank, or else I'll have to use a debugger to re-burn the flash).

 

Then, from within U-boot I can run ramboot, and if all goes well it should fetch the images and boot all the way into the new SDK.

ramboot.png

 

Eventually it should boot all the way to a linux prompt.

prompt.png

Attachments

    Outcomes