]>
Commit | Line | Data |
---|---|---|
56376c42 PA |
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 | |
93e14596 WD |
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. | |
56376c42 PA |
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. |