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. 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: Name Address rcw 0xe8000000 Linux.uImage 0xe8020000 uBoot 0xeff800000 fman uCode 0xeff40000 device tree 0xe8800000 linux rootfs 0xe9300000 To verify that this is correct, I can dump out my RCW: And I can also dump out my current U-boot (which should always start with an ASCII header identifying it): 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. 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. Apparently my sectors were protected. So I need to unprotect first, then erase again. 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: 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: 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: 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. Eventually it should boot all the way to a linux prompt. QorIQ P1 Devices QorIQ P2 Devices QorIQ P3 Devices QorIQ P4 Devices QorIQ P5 Devices Re: Deploying SDK 1.3.2 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 Re: Deploying SDK 1.3.2 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 ? Re: Deploying SDK 1.3.2 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 Re: Deploying SDK 1.3.2 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? Re: Deploying SDK 1.3.2 Hi, You can take a look to this response [1]. Regards, Marius [1] https://community.freescale.com/message/331578#331578 Re: Deploying SDK 1.3.2 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? Re: Deploying SDK 1.3.2 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. Re: Deploying SDK 1.3.2 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)? Re: Deploying SDK 1.3.2 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 Re: Deploying SDK 1.3.2 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. Re: Deploying SDK 1.3.2 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?
記事全体を表示
