u-boot.git/common/spl, branch v2017.03 Unnamed repository; edit this file 'description' to name the repository. SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig 2017-02-17T19:15:15+00:00 Dalon Westergreen dwesterg@gmail.com 2017-02-11T01:15:35+00:00 949123e30a61696610fc70ea89b1387eba0dace4 Added SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig. Due to SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION being moved to Kconfig the board defconfigs for db-88f6820-gp_defconfig kc1_defconfig and sniper_defconfig need to be updated. Signed-off-by: Dalon Westergreen <dwesterg@gmail.com> 
Added SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig.

Due to SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION being moved to
Kconfig the board defconfigs for db-88f6820-gp_defconfig
kc1_defconfig and sniper_defconfig need to be updated.

Signed-off-by: Dalon Westergreen <dwesterg@gmail.com>
SPL: add support to boot from a partition type 2017-02-17T19:15:14+00:00 Dalon Westergreen dwesterg@gmail.com 2017-02-11T01:15:34+00:00 f0fb4fa7d556379235723e755d8d56a811ac137f the socfpga bootrom supports mmc booting from either a raw image starting at 0x0, or from a partition of type 0xa2. This patch adds support for locating the boot image in the first type 0xa2 partition found. Assigned a partition number of -1 will cause a search for a partition of type CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE and use it to find the u-boot image Signed-off-by: Dalon Westergreen <dwesterg@gmail.com> 
the socfpga bootrom supports mmc booting from either a raw image
starting at 0x0, or from a partition of type 0xa2.  This patch
adds support for locating the boot image in the first type 0xa2
partition found.

Assigned a partition number of -1 will cause a search for a
partition of type CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
and use it to find the u-boot image

Signed-off-by: Dalon Westergreen <dwesterg@gmail.com>
spl: Allow PCH drivers to be used in SPL 2017-02-06T03:38:46+00:00 Simon Glass sjg@chromium.org 2017-01-16T14:03:33+00:00 bbe41abf7f0e4362dbadb2928489923db101691f Add an option for building Platorm Controller Hub drivers in SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Add an option for building Platorm Controller Hub drivers in SPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
spl: Allow timer drivers to be used in SPL 2017-02-06T03:38:46+00:00 Simon Glass sjg@chromium.org 2017-01-16T14:03:32+00:00 4a6c81ff42fc19ca82e8acc9562c6e077b9d11f1 Add a new Kconfig option to allow timer drivers to be used in SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Add a new Kconfig option to allow timer drivers to be used in SPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
spl: Allow RTC drivers to be used in SPL 2017-02-06T03:38:46+00:00 Simon Glass sjg@chromium.org 2017-01-16T14:03:31+00:00 30bf8a0dae205862c2e8b28ba1bd0a379a4fac1f Add a new Kconfig option to allow RTC drivers to be used in SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Add a new Kconfig option to allow RTC drivers to be used in SPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
spl: Allow PCI drivers to be used in SPL 2017-02-06T03:38:46+00:00 Simon Glass sjg@chromium.org 2017-01-16T14:03:30+00:00 2446b6b8f7de28c8d54d920f14e7027e2e64f4ef Add a new Kconfig option to allow PCI drivers to be used in SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Add a new Kconfig option to allow PCI drivers to be used in SPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
spl: Allow CPU drivers to be used in SPL 2017-02-06T03:38:46+00:00 Simon Glass sjg@chromium.org 2017-01-16T14:03:29+00:00 5e148df95216c0ee2e349a1cfb5b171ecc58632c Add a new Kconfig option to allow CPU drivers to be used in SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Add a new Kconfig option to allow CPU drivers to be used in SPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
spl: spi: Add a debug message if loading fails 2017-02-06T03:38:46+00:00 Simon Glass sjg@chromium.org 2017-01-16T14:03:27+00:00 a704490034c94b87bfe3fa992cc50b9a017b9d2b This currently fails silently. Add a debug message to aid debugging. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
This currently fails silently. Add a debug message to aid debugging.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
ARM: uniphier: change CONFIG_SPL_PAD_TO to 128KB 2017-01-29T11:59:08+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2017-01-27T21:53:53+00:00 c0efc3140e75e3ffd6127a5aec97b75347ec7417 The Boot ROM supports authentication feature to prevent malformed software from being run on products. The signature is added at the tail of the second stage loader (= SPL in U-boot terminology). The size of the second stage loader was 64KB, and it was consistent across SoCs. The situation changed when LD20 SoC appeared; it loads 80KB second stage loader, and it is the only exception. Currently, CONFIG_SPL_PAD_TO is set to 64KB and U-Boot proper is loaded from the 64KB offset of non-volatile devices. This means the signature of LD20 SoC (located at 80KB offset) corrupts the U-Boot proper image. Let's move the U-Boot proper image to 128KB offset. It uses 48KB for nothing but padding, and we could actually locate the U-Boot proper at 80KB offset. However, the power of 2 generally seems a better choice for the offset address. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 
The Boot ROM supports authentication feature to prevent malformed
software from being run on products.  The signature is added at the
tail of the second stage loader (= SPL in U-boot terminology).

The size of the second stage loader was 64KB, and it was consistent
across SoCs.  The situation changed when LD20 SoC appeared; it loads
80KB second stage loader, and it is the only exception.

Currently, CONFIG_SPL_PAD_TO is set to 64KB and U-Boot proper is
loaded from the 64KB offset of non-volatile devices.  This means the
signature of LD20 SoC (located at 80KB offset) corrupts the U-Boot
proper image.

Let's move the U-Boot proper image to 128KB offset.  It uses 48KB
for nothing but padding, and we could actually locate the U-Boot
proper at 80KB offset.  However, the power of 2 generally seems a
better choice for the offset address.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Revert "armv8: release slave cores from CPU_RELEASE_ADDR" 2017-01-28T19:04:38+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2017-01-20T09:30:58+00:00 7b74c4b60bd99dcec214c96d22c74f5ba6d8a29e This reverts commit 8c36e99f211104fd7dcbf0669a35a47ce5e154f5. There is misunderstanding in commit 8c36e99f2111 ("armv8: release slave cores from CPU_RELEASE_ADDR"). How to bring the slave cores into U-Boot proper is platform-specific. So, it should be cared in SoC/board files instead of common/spl/spl.c. As you see SPL is the acronym of Secondary Program Loader, there is generally something that runs before SPL (the First one is usually Boot ROM). How to wake up slave cores from the Boot ROM is really SoC specific. So, the intention for the spin table support is to bring the slave cores into U-Boot proper in an SoC specific manner. (this must be done after relocation. see below.) If you bring the slaves into SPL, it is SoC own code responsibility to transfer them to U-Boot proper. The Spin Table defines the interface between a boot-loader and Linux kernel. It is unrelated to the interface between SPL and U-Boot proper. One more thing is missing in the commit; spl_image->entry_point points to the entry address of U-Boot *before* relocation. U-Boot relocates itself between board_init_f() and board_init_r(). This means the master CPU sees the different copy of the spin code than the slave CPUs enter. The spin_table_update_dt() protects the code *after* relocation. As a result, the slave CPUs spin in unprotected code, which leads to unstable behavior. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
This reverts commit 8c36e99f211104fd7dcbf0669a35a47ce5e154f5.

There is misunderstanding in commit 8c36e99f2111 ("armv8: release
slave cores from CPU_RELEASE_ADDR").  How to bring the slave cores
into U-Boot proper is platform-specific.  So, it should be cared
in SoC/board files instead of common/spl/spl.c.  As you see SPL
is the acronym of Secondary Program Loader, there is generally
something that runs before SPL (the First one is usually Boot ROM).

How to wake up slave cores from the Boot ROM is really SoC specific.
So, the intention for the spin table support is to bring the slave
cores into U-Boot proper in an SoC specific manner.  (this must be
done after relocation.  see below.)

If you bring the slaves into SPL, it is SoC own code responsibility
to transfer them to U-Boot proper.  The Spin Table defines the
interface between a boot-loader and Linux kernel.  It is unrelated
to the interface between SPL and U-Boot proper.

One more thing is missing in the commit; spl_image->entry_point
points to the entry address of U-Boot *before* relocation.  U-Boot
relocates itself between board_init_f() and board_init_r().  This
means the master CPU sees the different copy of the spin code than
the slave CPUs enter.  The spin_table_update_dt() protects the code
*after* relocation.  As a result, the slave CPUs spin in unprotected
code, which leads to unstable behavior.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>