a46b1852 | 20-Nov-2015 |
Shengzhou Liu <Shengzhou.Liu@freescale.com> |
fsl/ddr: updated ddr errata-A008378 for arm and power SoCs
DDR errata-A008378 applies to LS1021-20-22A-R1.0, T1023-R1.0, T1024-R1.0, T1040-42-20-22-R1.0/R1.1, it has been fixed on LS102x Rev2.
Sign
fsl/ddr: updated ddr errata-A008378 for arm and power SoCs
DDR errata-A008378 applies to LS1021-20-22A-R1.0, T1023-R1.0, T1024-R1.0, T1040-42-20-22-R1.0/R1.1, it has been fixed on LS102x Rev2.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
show more ...
|
44d0677a | 06-Nov-2015 |
Måns Rullgård <mans@mansr.com> |
Replace "extern inline" with "static inline"
A number of headers define functions as "extern inline" which is causing problems with gcc5. The reason is that starting with version 5.1, gcc defaults
Replace "extern inline" with "static inline"
A number of headers define functions as "extern inline" which is causing problems with gcc5. The reason is that starting with version 5.1, gcc defaults to the standard C99 semantics for the inline keyword.
Under the traditional GNU inline semantics, an "extern inline" function would never create an external definition, the same as inline *without* extern in C99. In C99, and "extern inline" definition is simply an external definition with an inline hint. In short, the meanings of inline with and without extern are swapped between GNU and C99.
The upshot is that all these definitions in header files create an external definition wherever those headers are included, resulting in multiple definition errors at link time.
Changing all these functions to "static inline" fixes the problem since this works as desired in all gcc versions. Although the semantics are slightly different (a static inline definition may result in an actual function being emitted), it works as intended in practice.
This patch also removes extern prototype declarations for the changed functions where they existed.
Signed-off-by: Mans Rullgard <mans@mansr.com>
show more ...
|
8fe11b89 | 01-Sep-2015 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
powerpc: ppc4xx: remove lwmon5 support
This has not been converted to Generic Board, so should be removed. (See doc/README.generic-board for details.)
Remove CONFIG_LWMON5 references. (Also, remove
powerpc: ppc4xx: remove lwmon5 support
This has not been converted to Generic Board, so should be removed. (See doc/README.generic-board for details.)
Remove CONFIG_LWMON5 references. (Also, remove undefined CONFIG_WD_MAX_RATE while I am here.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Stefan Roese <sr@denx.de>
show more ...
|
5050f6f0 | 16-Jun-2015 |
Aneesh Bansal <aneesh.bansal@freescale.com> |
powerpc/mpc85xx: SECURE BOOT-Copy Boot Script on RAM
For running Chain of Trust when doing Secure Boot from NAND, the Bootscript header and bootscript must be copied from NAND to RAM(DDR). The addre
powerpc/mpc85xx: SECURE BOOT-Copy Boot Script on RAM
For running Chain of Trust when doing Secure Boot from NAND, the Bootscript header and bootscript must be copied from NAND to RAM(DDR). The addresses and commands for the same have been defined.
Signed-off-by: Saksham Jain <saksham@freescale.com> Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
show more ...
|
467a40df | 16-Jun-2015 |
Aneesh Bansal <aneesh.bansal@freescale.com> |
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
Secure Boot Target is added for NAND for P3041. For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC. In case of secure
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
Secure Boot Target is added for NAND for P3041. For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC. In case of secure boot, this default address maps to Boot ROM. The Boot ROM code requires that the bootloader(U-boot) must lie in 0 to 3.5G address space i.e. 0x0 - 0xDFFFFFFF.
In case of NAND Secure Boot, CONFIG_SYS_RAMBOOT is enabled and CPC is configured as SRAM. U-Boot binary will be located on SRAM configured at address 0xBFF00000. In the U-Boot code, TLB entries are created to map the virtual address 0xFFF00000 to physical address 0xBFF00000 of CPC configured as SRAM.
Signed-off-by: Saksham Jain <saksham@freescale.com> Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
show more ...
|
1ff10a87 | 20-May-2015 |
Nikhil Badola <nikhil.badola@freescale.com> |
powerpc/mpc85xx: Correct CONFIG_USB_MAX_CONTROLLER_COUNT for p1025
Correct the value CONFIG_USB_MAX_CONTROLLER_COUNT macro to 1 for p1025 as it has one USB controller
Signed-off-by: Nikhil Badola <
powerpc/mpc85xx: Correct CONFIG_USB_MAX_CONTROLLER_COUNT for p1025
Correct the value CONFIG_USB_MAX_CONTROLLER_COUNT macro to 1 for p1025 as it has one USB controller
Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
show more ...
|
2d9ca2c7 | 22-Apr-2015 |
Yangbo Lu <yangbo.lu@freescale.com> |
mmc: fsl_esdhc: Add peripheral clock support
The SD clock could be generated by platform clock or peripheral clock for some platforms. This patch adds peripheral clock support for T1024/T1040/T2080.
mmc: fsl_esdhc: Add peripheral clock support
The SD clock could be generated by platform clock or peripheral clock for some platforms. This patch adds peripheral clock support for T1024/T1040/T2080. To enable it, define CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK.
Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com> Cc: York Sun <yorksun@freescale.com> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Reviewed-by: York Sun <yorksun@freescale.com>
show more ...
|