On Thu, Nov 10, 2011 at 11:12:41AM -0600, Timur Tabi wrote: > Ira W. Snyder wrote: > > Hello Timur, Kumar, U-Boot List, > > > > I'm working on porting U-Boot to the Freescale P2020 COM-Express board. > > See the ML post from 2011-09-27 titled "[PATCH 0/2] mpc85xx: support for > > Freescale COM Express P2020". > > I see that you are using a NAND boot, which is a multi-stage boot. There are > some problems with that that have been fixed in recent patches posted by me > and Kumar to the U-boot mailing list. > > In particular, one patches puts U-boot into an infinite loop if CCSR is > relocated in the wrong step. >
I don't use NAND, nor any multi-stage boot (as far as I know). I boot off of SDCARD (P2020COME_SDCARD_config). To write the U-Boot image to the microSD card, I use a tool provided with the BSP called "boot_format-1.0.0". Maybe you are familiar with it? > > When it was posted, the port was working on the top of tree U-Boot. This > > included relocation of the CCSRBAR from the power on location of > > 0xff700000 to 0xffe00000. > > Is there a reason why you want to relocate CCSR at all? Everything would be > a lot easier if you just left it at the default location. I have a suspicion > that many boards relocate CCSR just for the heck of it. > > However, Kumar's recent rework of the device trees may force all P2020 boards > to have the same CCSR, so you might be stuck. > I relocate the CCSR because my device tree requires it. I wanted to use the Linux arch/powerpc/boot/dts/p2020si.dtsi as a base, and override the few things that are specific to this board. It requires the CCSR be relocated to 0xffe00000. I'll look at Kumar's DTS changes. I saw them on the Linux PPC ML. > > Today I updated U-Boot to top of tree to address the comments in the > > initial mailing list posting. Upon attempting to boot the board, I get > > no console output. I have traced this to commit 6ca88b0958 > > ("powerpc/85xx: relocate CCSR before creating the initial RAM area"). > > This patch requires that only the last stage of U-Boot (i.e. the "real" > U-Boot) relocate CCSR. All previous stages must not relocate CCSR. This is > a change from the way we were doing things in the past. > I understand that. I only use one U-Boot. To the best of my knowledge, boot on this platform works like this: - power on - the P2020 looks for the magic "BOOT" written by the boot_format tool on the SD card - the P2020 executes the instructions written by boot_format to setup RAM correctly, load the U-Boot from the SD card to RAM, and then jumps to it - U-Boot runs, including relocating CCSR Only one U-Boot is ever executed. > > Indeed, making sure that the code does not run by adding the following > > to my board config file causes U-Boot to start correctly. Though the > > CCSRBAR is not relocated, as expected. > > > > #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE > > If you set this macro and your DTS puts CCSR at 0xffe00000, then you won't be > able to boot Linux (or any OS that uses the device tree). > Of course. I have to get U-Boot working before I can boot any OS. This was a way to test that the new code causes U-Boot to fail, nothing more. It proved that there is something wrong with relocation on my board. > > As an alternative, reverting the commit causes my board to work again. > > The CCSRBAR is relocated correctly. > > The new CCSR relocation method is needed to standardize the way we handle > that task and to support future SOCs that require CCSR to be relocated > earlier in the boot process. I admit that it can sneak up on people, like it > did for you, but the new approach is necessary. In the end, it will make > everything a lot easier. > I understand that. Has the current top of tree been tested on P2020DS? I'm looking for some assurance that the code I'm trying to use actually works on a !CONFIG_FSL_CORENET platform which relocates the CCSR. One in-tree example is the P2020DS. > > The P2020DS board is very similar to the board I am using. It performs > > the same relocation of the CCSRBAR that I want to use as well. Does > > anyone have a P2020DS that they can test with the current top of tree > > U-Boot? Does it boot? Can you send the output of "md ffe00000 1"? > > Kumar recently posted a patch that fixes the relocation on multi-stage > U-Boots (e.g. NAND booting, SPI booting, etc). I also posted a patchset last > week that fixes a few problems with > Can you tell me the subject lines of these patches? Even though I don't use a multi-stage U-Boot, I'll check them out. Thanks for the reply, Ira _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot