
Hi,
I try to port U-Boot 1.3.4 on a custom MPC8270 card. I'm very new to PowerPC and U-Boot, I'm therefore a little lost in the huge set of documentation and most likely have silly questions.
My board has the following main characteristics: - 128 MB SDRAM - 32 MB Flash (4xAM29LV641) mapped at 0xF4000000 - 3x MPC8270 cores (one master, 2 slaves) - 60x is used instead of local bus - PCI unused - RS232 on SMC2 - HWCW configured by a PLD and used since years
As a first step, I would like to have a serial console output, but I did not succeed yet:
I figured that it is not that far from PQ2FADS, therefore I took this configuration as my base.
1. I added CONFIG_API and DEBUG in my config
2. I figured from HWCW value that I needed lowboot, and have set TEXT_BASE to start address of u-boot in flash, 0xF4000000 (I have read again "System Initialization" but I'm not yet certain of this).
3. I defined CONFIG_CONS_ON_SMC, undefined CONFIG_CONS_ON_SCC and set CONFIG_CONS_INDEX to 2
4. CONFIG_8260_CLKIN is set to 100Mhz with PQ2FADS so I think and don't need to change that.
5. I flashed (with trace32 on Linux) u-boot.bin at 0xF4000000 (first flash address)
With the debugger, I can see that 0x100 is executed first and contains my u-boot code (li r21, 0x1). But it then crashes at first init_8260_core instructions. Of course, no data comes yet from the serial port.
Any help or documentation pointing would be greatly appreciated, so that I can finally see this famous U-Boot prompt ;)
Best regards, Rémi Lefevre

Ok, I made some progress.
I realized that my debugger was not correctly initialized and was preventing accurate stepping. So if you use a Lauterbach with Trace32 and MPC8270, it seems that you have to reset OR11 & BR11 to 0 in the init script (FYI).
Anyway, I have set my board configuration with the following mapping: SDRAM 0x0000 0000 0x07FF FFFF DPRAM Proc 1 0xF000 0000 0xF013 FFFF ... (slaves and misc) ... Flash 1 0xF400 0000 0xF4FF FFFF Flash 2 0xF500 0000 0xF5FF FFFF
U-Boot starts at 0x100, jumps into flash ("in_flash:"), but then hangs in "init_debug:", when trying to move the DPRAM:
/* Set the entire dual port RAM (where the initial stack */ /* resides) to a known value - makes it easier to see where */ /* the stack has been written */ /*----------------------------------------------------------*/ lis r3, (CFG_IMMR + CFG_INIT_SP_OFFSET)@h ori r3, r3, (CFG_IMMR + CFG_INIT_SP_OFFSET)@l li r4, ((CFG_INIT_SP_OFFSET - 4) / 4) mtctr r4 lis r4, 0xdeadbeaf@h ori r4, r4, 0xdeadbeaf@l
stwu r4, -4(r3) | bdnz 1b | <- U-Boot loops there then hangs at 0x00000800 or sometimes near 0x00000600
CFG_IMMR (and therefore CFG_INIT_RAM_ADDR) is set to 0xF0000000 so it seems correct. The constant "0xdeadbeaf" is still a little obscure to me...
- Any idea what I'm missing ? - Also, if you see obvious incompatibility between my mapping and the Linux kernel, I would be glad to know it.
Best regards, Rémi Lefevre
On Wed, Sep 10, 2008 at 9:20 PM, Remi Lefevre rlefevre@gmail.com wrote:
My board has the following main characteristics:
- 128 MB SDRAM
- 32 MB Flash (4xAM29LV641)
- 3x MPC8270 cores (one master, 2 slaves)
- 60x is used instead of local bus
- PCI unused
- RS232 on SMC2
- HWCW configured by a PLD and used since years

U-Boot 1.3.4 (Sep 12 2008 - 19:16:33)
MPC8270 Reset Status: External Soft, External Hard MPC8270 Clock Configuration - Bus-to-Core Mult 5x, VCO Div 2, 60x Bus Freq 20-60 , Core Freq 100-300 - dfbrg 0, corecnf 0x1b, busdf 6, cpmdf 1, plldf 0, pllmf 6, pcidf 3 - vco_out 583331000, scc_clk 145832750, brg_clk 145832750 - cpu_clk 416665000, cpm_clk 291665500, bus_clk 83333000 CPU: MPC8270 (HiP7 Rev 14, Mask 1.0 1K49M) at 416.665 MHz Board: DMYx MPC8270 DRAM: 128 MB
Well, I have to admit it was quite an emotion to see this the first time!
Top of RAM usable for U-Boot at: 08000000 Reserving 227k for U-Boot at: 07fc7000 Reserving 4224k for malloc() at: 07ba7000 Reserving 84 Bytes for Board Info at: 07ba6fac Reserving 76 Bytes for Global Data at: 07ba6f60
So far so good, but...
Stack Pointer at: 07ba6f48 New Stack Pointer is: 07ba6f48 ?~??o (<- garbage characters then nothing)
I can't say I'm surprised. I expected some trouble in the relocation. As others before me, the u-boot code is correctly copied in RAM, the code run from "in_ram:", but hangs in "trap_init:".
From the FAQ and mailing list, I would assume I hit the
"99% relocation problems come from burst mode" issue. But I don't really know where to investigate. From the manual of my SDRAM (MT48LC16M16A2), the init sequence is very similar to eg. ep82xxm's one.
Could this be a timing issue ? I don't see much timing in ep82xxm code for example. Or perhaps the MRW configuration is not enough to correctly configure burst mode ? (Of course I'm also new in SDRAM init...)
Thanks for ELDK and U-Boot, they are really great.
Best regards, Rémi Lefevre

[sorry, message has been cut]
Could this be a timing issue ? I don't see much timing in ep82xxm code for example. Or perhaps the MRW configuration is not enough to correctly configure burst mode ? (Of course I'm also new in SDRAM init...)
Thanks for ELDK and U-Boot, they are really great.
Best regards, Rémi Lefevre
participants (1)
-
Remi Lefevre