Hi Chaya,
There are some items that I want to outline here:
1. First of all, every peripheral can be mapped wherever in the physical/virtual space (there is no standard requirement for this) - that's why there are some un-synchronized memory areas between CW and u-boot. The only trick here is to have a correctly initialization flow: MMU/TLB, LAW (Local Access Windows) and CS (ORx/BRx eLBC in your case). Like a conclusion if you're using the CW please use the initialization from tcl file and flash target task, if you're using the u-boot/SDK please take a look in the SDK infocenter documentation (available online here [1] )
2. Secondly, about your last question. Any e500* core boots/start up by default with 4KB window in the TLB (virtual space 0xFFFF_F000 mapped to physical space 0xFFFF_F000 - this is 1:1 as you can simply observe). So, the u-boot just use this memory map at start-up. Now, in the second stage, the u-boot will re-allocate itself to a new memory flash range using some special mechanism (rfi - recall from interrupt) to a new memory area (the one specific by you into the last thread). Please note that in BR0 eLBC, you'll need to have the virtual address range for that peripheral (NOR in this case) - that's why the u-boot will full-fill BR0 with 0xEFXX_XXXX.
Taking a look over your last questions, I observed you have some issues related the UART/u-boot doesn't boot up correctly - no output is observed by you in the UART console. I suggest you 2 things:
1. You can try to make a Debug Download from CodeWarrior and to see if the printf("Welcome to CodeWarrior") message will be shown in the UART console.
2. Attach to a (possible) running u-boot using CodeWarrior, stop the target and try to read the PC (program counter register). If the PC is in RAM (address between 0x0 and 0x7FFF_FFFF) the u-boot booted up correctly. Also you can check the RAM from debugger shell trying to write/read the same memory zone.
Hope this helps,
Marius
[1] Welcome to the Linux SDK for QorIQ Processors Infocenter
