Hi
Our board having P1020RDB-PC processor , Nor flash got corrupted so want re-flash the NOR flash,,,,,
our Board-Bring-up document show that NOR FLASH MEMORY MAPPED ADREESSS is show below, But as per the codewarrior development tool, we have to start the base address 0XFF000000,,,, Can u tell me why We have start from this base address , and why we cont start from oxEF000000 this base address,,,,,,,,,,,, could u please give the resone…………
Start Address | End Address | Description | Size |
0xef00_0000 | 0xef03_ffff | Vitesse 7385 Switch Firmware | 256K |
0xef04_0000 | 0xef07_ffff | dtb image | 256K |
0xef08_0000 | 0xef3f_ffff | Uimage |
|
0xef40_0000 | 0xefef_ffff | JFFS2 image | 11M |
0xeff0_0000 | 0xefff_ffff | u-boot(at eff80000) and it's env (at eff60000) | 1M |
Please take a look on this thread: https://community.freescale.com/message/331535#331535 . You will find more information about processor booting process.
Adrian
Hi
I am very beginner to this stuffs,,, could u please tell why it will translate the address from 0XEF00_0000 TO 0XFFFF_XXXX,,, I didn’t understand this why base address 0XEF00_0000 is translating to 0XFFFF_XXXX
Regards
chaya
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
Hi
"Welcome to CodeWarrior" this message is not displaying on the uart console .