Poonam Aggrwal | 56376c4 | 2013-03-25 07:30:06 +0000 | [diff] [blame] | 1 | RAMBOOT for MPC85xx Platforms |
| 2 | ============================== |
| 3 | |
| 4 | RAMBOOT literally means boot from DDR. But since DDR is volatile memory some |
| 5 | pre-mechanism is required to load the DDR with the bootloader binary. |
| 6 | - In case of SD and SPI boot this is done by BootROM code inside the chip |
| 7 | itself. |
| 8 | - In case of NAND boot FCM supports loading initial 4K code from NAND flash |
| 9 | which can initialize the DDR and get the complete bootloader copied to DDR. |
| 10 | |
| 11 | In addition to the above there could be some more methods to initialize the DDR |
| 12 | and load it manually. |
| 13 | Two of them are described below.There is also an explanation as to where these |
| 14 | methods could be handy. |
| 15 | 1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then |
| 16 | execute the bootloader from DDR. |
| 17 | This may be handy in the following cases: |
| 18 | - In very early stage of platform bringup where other boot options are not |
| 19 | functional because of various reasons. |
| 20 | - In case the support to program the flashes on the board is not available. |
| 21 | |
| 22 | 2. Load the RAM based bootloader onto DDR using already existing bootloader on |
| 23 | the board.And then execute the bootloader from DDR. |
| 24 | Some usecases where this may be used: |
| 25 | - While developing some new feature of u-boot, for example USB driver or |
Wolfgang Denk | 93e1459 | 2013-10-04 17:43:24 +0200 | [diff] [blame] | 26 | SPI driver. |
| 27 | Suppose the board already has a working bootloader on it. And you would |
| 28 | prefer to keep it intact, at the same time want to test your bootloader. |
| 29 | In this case you can get your test bootloader binary into DDR via tftp |
| 30 | for example. Then execute the test bootloader. |
Poonam Aggrwal | 56376c4 | 2013-03-25 07:30:06 +0000 | [diff] [blame] | 31 | - Suppose a platform already has a propreitery bootloader which does not |
| 32 | support for example AMP boot. In this case also RAM boot loader can be |
| 33 | utilized. |
| 34 | |
| 35 | So basically when the original bootloader is required to be kept intact |
| 36 | RAM based bootloader can offer an updated bootloader on the system. |
| 37 | |
| 38 | Both the above Bootloaders are slight variants of SDcard or SPI Flash |
| 39 | bootloader or for that matter even NAND bootloader. |
| 40 | All of them define CONFIG_SYS_RAMBOOT. |
| 41 | The main difference among all of them is the way the pre-environment is getting |
| 42 | configured and who is doing that. |
| 43 | - In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself. |
| 44 | - In case of NAND boot SPL/TPL code does it with some support from Si itself. |
| 45 | - In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader. |
| 46 | |
| 47 | How to use them: |
| 48 | 1. Using JTAG |
| 49 | Boot up in core hold off mode or stop the core after reset using JTAG |
| 50 | interface. |
| 51 | Preconfigure DDR/L2SRAM through JTAG interface. |
| 52 | - setup DDR controller registers. |
| 53 | - setup DDR LAWs |
| 54 | - setup DDR TLB |
| 55 | Load the RAM based boot loader to the proper location in DDR/L2SRAM. |
| 56 | set up IAR (Instruction counter properly) |
| 57 | Enable the core to execute. |
| 58 | |
| 59 | 2. Using already existing bootloader. |
| 60 | get the rambased boot loader binary into DDR/L2SRAM via tftp. |
| 61 | execute the RAM based bootloader. |
| 62 | => tftp 11000000 u-boot-ram.bin |
| 63 | => go 1107f000 |
| 64 | |
| 65 | Please note that L2SRAM can also be used instead of DDR if the SOC has |
| 66 | sufficient size of L2SRAM. |
| 67 | |
| 68 | Necessary Code changes Required: |
| 69 | ===================================== |
| 70 | Please note that below mentioned changes are for 85xx platforms. |
| 71 | They have been tested on P1020/P2020/P1010 RDB. |
| 72 | |
| 73 | The main difference between the above two methods from technical perspective is |
| 74 | that in 1st case SOC is just out of reset so it is in default configuration. |
| 75 | (CCSRBAR is at 0xff700000). |
| 76 | In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000 |
| 77 | |
| 78 | 1. File name-> boards.cfg |
| 79 | There can be added specific Make options for RAMBoot. We can keep different |
| 80 | options for the two cases mentioned above. |
| 81 | for example |
| 82 | P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT. |
| 83 | |
| 84 | 2. platform config file |
| 85 | for example include/configs/P1_P2_RDB.h |
| 86 | |
| 87 | #ifdef CONFIG_RAMBOOT |
| 88 | #define CONFIG_SDCARD |
| 89 | #endif |
| 90 | |
| 91 | This will finally use the CONFIG_SYS_RAMBOOT. |
| 92 | |
| 93 | 3. File name-> arch/powerpc/include/asm/config_mpc85xx.h |
| 94 | In the section of the particular SOC, for example P1020, |
| 95 | |
| 96 | #if defined(CONFIG_GO) |
| 97 | #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000 |
| 98 | #else |
| 99 | #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 |
| 100 | #endif |
| 101 | |
| 102 | For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000. |