Deploying SDK 1.3.2

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploying SDK 1.3.2

Deploying SDK 1.3.2

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

Comments

Is this loading method will make all the cores running the same image?

And for the putty output, how can we know which core is printing the content?

Good question. What I was showing here was U-boot, loading an SMP image of Linux. U-boot only runs on one core, and Linux will run across all cores. There are other options, and if you wanted to run AMP Linux, or Linux plus other OS'es (VxWorks, OSE etc...) you would need to use a hypervisor.

But, what I built and ran here above was U-boot on core0 launching SMP linux.

I was just reading through the SDK 1.3.2 documentation, section 7.2.5 shows an example of how to bring up two instances of U-boot and Linux (on two separate cores).

Here's a link to the document on infocenter:

Freescale Technical Information Center

Thanks for the good article(s). You mentioned in this article:

The NOR on these development systems is banked, meaning that the most significant address line is tied to a DIP switch

I was wondering where the documentation is available that describes the various settings of how to changed which bank for the NOR is being used along with what the other DIP switches on the P3041DS do. All I've been able to find is the default values for the DIP switches from the SDK.

Could you point me to a link to the documentation that describes the P3041DS hardware in more detail (specifically the DIP switches)?

Hi Ryan, I think it is mentioned on Infocenter  here

http://www.freescale.com/infocenter/topic/QORIQSDK/3102519.html

Freescale documentation is still fragmented anyway.

Hi Paul, i have one question:

For this scenario, RCW is loaded from NOR flash and then it will say BOOT_LOC is also from NOR flash. How does the processor know which address from BOOT_LOC to fetch  as this is not indicated in RCW?

Hi,

You can take a look to this response [1].

Regards,

Marius

[1] https://community.freescale.com/message/331578#331578

Marius,

I have read the answer and it is very useful. Nevertheless, I am writing here again my interpretation hopefully you can clarify with me if my understanding is correct:

Say we set the RCW source to NOR flash and also within RCW we set BOOT_LOC to NOR Flash as well.

At boot up, RCW is fetched from CS0 address 0x00000000 and then is decoded. Based on the BOOT_LOC value,  the value of Bootspace translation registers LCC_BSTRx (high, low, attribute) are updated accordingly to map the boot window space (from 0xFF800000 to 0xFFFFFFFF) to eLBC NOR Flash (at which  address??). From here I have no idea how is the u-boot loaded in and executed?

Ok, let's try to reformulate this in less or more common words.

1. You must select the Boot_location from RCW according with your device controller (e.g. eLBC, i2c, IFC, eSPI, eSDHC and so on). In this case should be eLBC 16bits mode -  you can see this setting more like a processor specific setting.

2. According with first step you need to select from DIP SW settings and the desired boot device (NOR, NAND, SPI, SD, I2C and so on) - this is needed because you can have multiple flashes and the processor can't know from what device you want to boot up - you can see this setting more like a board specific setting.

3. Now, based on the first 2 steps, the processor can boot up in a specific combination. In the case of the NOR booting up, the processor has a capability (using OR0/BR0 registers) to map the last part of the flash (this contains u-boot code) over the reset memory area (0xFFFF_FFFC). Let's say that 0xFFFF_FFFC will point to 0xXFFF_FFFC in the NOR flash (where X can be any - e.g. it can be 'E' when you flashed the u-boot starting with 0xEFF8_0000) - this is just to imagine by yourself how it works, but this space 0xEFxx_xxxx doesn't exist during reset/booting time.

Regarding the RCW fetching, the processor fetches it based on the DIP SW settings from the selected boot device - whatever the device is, always the RCW is fetched from the beginning.

Hope that helps,

Marius

Marius,

1. You must select the Boot_location from RCW according with your device controller (e.g. eLBC, i2c, IFC, eSPI, eSDHC and so on). In this case should be eLBC 16bits mode -  you can see this setting more like a processorspecific setting.

Regarding the RCW fetching, the processor fetches it based on the DIP SW settings from the selected boot device - whatever the device is, always the RCW is fetched from the beginning.

--> ok, so RCW is always fetched from address 0x00000000  no matter what device is specified at rcw_src. When it comes to the NOR Flash, the actual address is 0xe8000000 thanks to some address bus manipulation & banking done by ngPixis.


2. According with first step you need to select from DIP SW settings and the desired boot device (NOR, NAND, SPI, SD, I2C and so on) - this is needed because you can have multiple flashes and the processor can't know from what device you want to boot up - you can see this setting more like a board specific setting.

--> ok so we  have to specify the boot device at two places: in RCW and onboard switches. The onboard SW is to tell the ngPixis to select the right chip NAND/NOR, etc when processor starts fetching at CS0/OR0/BR0 am I right?

3. Now, based on the first 2 steps, the processor can boot up in a specific combination. In the case of the NOR booting up, the processor has a capability (using OR0/BR0 registers) to map the last part of the flash (this contains u-boot code) over the reset memory area (0xFFFF_FFFC). Let's say that 0xFFFF_FFFC will point to 0xXFFF_FFFC in the NOR flash (where X can be any - e.g. it can be 'E' when you flashed the u-boot starting with 0xEFF8_0000) - this is just to imagine by yourself how it works, but this space 0xEFxx_xxxx doesn't exist during reset/booting time.

--> Now this is the part where I would like to clarify my understanding of what actually happens:

The processor start fetching from effective address 0xffff_fffc which falls into boot window space. Before this, based on RCW which is setting BOOT_LOC to point to eLBC NOR flash, the processor already configures boot space translation registers to select eLBC ID and the translation registers high/low are still 0 by reset. Now eLBC has to use CS0/OR0/BR0 by default to access NOR Flash; the base value for BR0 is still 0 by reset, and FCM is selected. Up until this stage the address lines coming out eLBC onto the the processor pin is still 0xffff_fffc am I correct? Now with with external logics as well as control from ngPixis, when the address lines reach the NOR Flash, it will be 0xEFFFFFFC ?

1. RCW is always fetched from address 0x00000000 - this is true.

When it comes to the NOR Flash, the actual address is 0xe8000000 thanks to some address bus manipulation & banking done by ngPixis. - in fact when the processor is booting up it see the NOR device only during interim state mapped from 0x0 (due of the OR0/BR0 register setting). Basically the flash contain is mapped multiple times through the SoC memory space - the same content of the flash will be visible in multiple window memory zones - just after reallocation (after the u-boot changes the OR0/BR0) you have absolute addressing.


2. You're right.


3. Up until this stage the address lines coming out eLBC onto the the processor pin is still 0xffff_fffc am I correct? - the addressing is with 0xffff_xxxx addresses - you're right

Now with with external logics as well as control from ngPixis, when the address lines reach the NOR Flash, it will be 0xEFFFFFFC ? - in the first stage the u-boot re-map the u-boot zone anywhere it wants (historically the u-boot chose this 0xefxx_xxxx zone) using BR0/OR0, LAW and TLB registers. After all these settings a rfi  instruction is called (the return address - 0xEFxx_xxxx is set up in SRR0 and the MSR in SRR1). You can make also u-boot debug using CodeWarrior to see all this behavior.


Regards,

Marius

Version history
Revision #:
1 of 1
Last update:
‎05-01-2013 01:03 PM
Updated by: