[U-Boot] [PATCH v4 14/19] arm: socfpga: Add SPL support for Arria 10

Dinh Nguyen dinh.linux at gmail.com
Tue Apr 11 12:28:55 UTC 2017


On Tue, Apr 11, 2017 at 12:48 AM, Ley Foon Tan <lftan.linux at gmail.com> wrote:
> On Tue, Apr 11, 2017 at 11:42 AM, Dinh Nguyen <dinguyen at kernel.org> wrote:
>>
>>
>> On 04/10/2017 05:05 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/10/2017 03:43 PM, Dinh Nguyen wrote:
>>>>
>>>>
>>>> On 04/05/2017 04:32 AM, Ley Foon Tan wrote:
>>>>> Add SPL support for Arria 10.
>>>>>
>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>> Signed-off-by: Ley Foon Tan <ley.foon.tan at intel.com>
>>>>> ---
>>>>>  arch/arm/mach-socfpga/spl.c | 74 ++++++++++++++++++++++++++++++++++++++++++---
>>>>>  1 file changed, 69 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
>>>>> index 69c433c..e1e62c2 100644
>>>>> --- a/arch/arm/mach-socfpga/spl.c
>>>>> +++ b/arch/arm/mach-socfpga/spl.c
>>>>> @@ -19,23 +19,32 @@
>>>>>  #include <asm/arch/sdram.h>
>>>>>  #include <asm/arch/scu.h>
>>>>>  #include <asm/arch/nic301.h>
>>>>> +#include <asm/sections.h>
>>>>> +#include <fdtdec.h>
>>>>> +#include <watchdog.h>
>>>>> +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
>>>>> +#include <asm/arch/pinmux.h>
>>>>> +#endif
>>>>>
>>>>>  DECLARE_GLOBAL_DATA_PTR;
>>>>>
>>>>> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>>>>>  static struct pl310_regs *const pl310 =
>>>>>     (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
>>>>>  static struct scu_registers *scu_regs =
>>>>>     (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
>>>>>  static struct nic301_registers *nic301_regs =
>>>>>     (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
>>>>> -static struct socfpga_system_manager *sysmgr_regs =
>>>>> +#endif
>>>>> +
>>>>> +static const struct socfpga_system_manager *sysmgr_regs =
>>>>>     (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
>>>>>
>>>>>  u32 spl_boot_device(void)
>>>>>  {
>>>>>     const u32 bsel = readl(&sysmgr_regs->bootinfo);
>>>>>
>>>>> -   switch (bsel & 0x7) {
>>>>> +   switch (SYSMGR_GET_BOOTINFO_BSEL(bsel)) {
>>>>>     case 0x1:       /* FPGA (HPS2FPGA Bridge) */
>>>>>             return BOOT_DEVICE_RAM;
>>>>>     case 0x2:       /* NAND Flash (1.8V) */
>>>>> @@ -68,6 +77,7 @@ u32 spl_boot_mode(const u32 boot_device)
>>>>>  }
>>>>>  #endif
>>>>>
>>>>> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>>>>>  static void socfpga_nic301_slave_ns(void)
>>>>>  {
>>>>>     writel(0x1, &nic301_regs->lwhps2fpgaregs);
>>>>> @@ -85,6 +95,7 @@ void board_init_f(ulong dummy)
>>>>>  #endif
>>>>>     unsigned long sdram_size;
>>>>>     unsigned long reg;
>>>>> +   int ret;
>>>>>
>>>>>     /*
>>>>>      * First C code to run. Clear fake OCRAM ECC first as SBE
>>>>> @@ -117,7 +128,11 @@ void board_init_f(ulong dummy)
>>>>>     /* Put everything into reset but L4WD0. */
>>>>>     socfpga_per_reset_all();
>>>>>     /* Put FPGA bridges into reset too. */
>>>>> -   socfpga_bridges_reset(1);
>>>>> +   ret = socfpga_bridges_reset(1);
>>>>> +   if (ret) {
>>>>> +           printf("socfpga_bridges_reset() failed: %d\n", ret);
>>>>> +           hang();
>>>>> +   }
>>>>>
>>>>>     socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
>>>>>     socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
>>>>> @@ -150,7 +165,11 @@ void board_init_f(ulong dummy)
>>>>>
>>>>>     /* De-assert reset for peripherals and bridges based on handoff */
>>>>>     reset_deassert_peripherals_handoff();
>>>>> -   socfpga_bridges_reset(0);
>>>>> +   ret = socfpga_bridges_reset(0);
>>>>> +   if (ret) {
>>>>> +           printf("socfpga_bridges_reset() failed: %d\n", ret);
>>>>> +           hang();
>>>>> +   }
>>
>> I managed to debug the hang of the Atlas board to this function call.
>> socfpga_bridges_reset is indeed returning an error from the FPGA, just
>> the hang() is called.
>>
>> The error is not caused by this patch, but is exposed by this patch.
>> Will have to debug why the fpgamgr_test_fpga_ready() call from
>> socfpga_bridges_reset(0) is returning an error.
>>
> I've tested with our CV SoC devkit, it can bootup to U-boot stage.
> Thanks help to debug.
>

I also tested on the CV devkit. It was fine. Make sure you test
this series on as many variations of HW as you can.

Dinh


More information about the U-Boot mailing list