[U-Boot] [RFC PATCH 4/6] x86: Add basic Intel Quark processor support

[Simon Glass <sjg@chromium.org>]

Hi Bin,

On 28 January 2015 at 19:17, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Jan 29, 2015 at 2:05 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 28 January 2015 at 07:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Add minimum codes to support Intel Quark SoC. DRAM initialization
>>> is not ready yet so a hardcoded gd->ram_size is assigned.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>>  arch/x86/cpu/quark/Kconfig             | 63 ++++++++++++++++++++++++++++++
>>>  arch/x86/cpu/quark/Makefile            |  8 ++++
>>>  arch/x86/cpu/quark/dram.c              | 39 +++++++++++++++++++
>>>  arch/x86/cpu/quark/pci.c               | 70 ++++++++++++++++++++++++++++++++++
>>>  arch/x86/cpu/quark/quark.c             | 44 +++++++++++++++++++++
>>>  arch/x86/include/asm/arch-quark/gpio.h | 13 +++++++
>>>  6 files changed, 237 insertions(+)
>>>  create mode 100644 arch/x86/cpu/quark/Kconfig
>>>  create mode 100644 arch/x86/cpu/quark/Makefile
>>>  create mode 100644 arch/x86/cpu/quark/dram.c
>>>  create mode 100644 arch/x86/cpu/quark/pci.c
>>>  create mode 100644 arch/x86/cpu/quark/quark.c
>>>  create mode 100644 arch/x86/include/asm/arch-quark/gpio.h
>>>
>>> diff --git a/arch/x86/cpu/quark/Kconfig b/arch/x86/cpu/quark/Kconfig
>>> new file mode 100644
>>> index 0000000..a71cc6c
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/quark/Kconfig
>>> @@ -0,0 +1,63 @@
>>> +#
>>> +# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
>>> +#
>>> +# SPDX-License-Identifier:     GPL-2.0+
>>> +#
>>> +
>>> +config INTEL_QUARK
>>> +       bool
>>> +       select HAVE_RMU
>>> +
>>> +if INTEL_QUARK
>>> +
>>> +config HAVE_RMU
>>> +       bool "Add a Remote Management Unit (RMU) binary"
>>> +       help
>>> +         Select this option to add a Remote Management Unit (RMU) binary
>>> +         to the resulting U-Boot image. It is a data block (up to 64K) of
>>> +         machine specific code which must be put in the flash for the RMU
>>
>> machine-specific
>
> OK.
>
>>> +         within the Quark SoC processor to access when powered up before
>>> +         system BIOS is executed.
>>
>> So does this happen before the reset vector?!
>
> Looks like so. This is something like Tunnel Creek's CMC, as you see
> below I mapped RMU_xxx to CMC_xxx.
>
>>> +
>>> +config RMU_FILE
>>> +       string "Remote Management Unit (RMU) binary filename"
>>> +       depends on HAVE_RMU
>>> +       default "rmu.bin"
>>> +       help
>>> +         The filename of the file to use as Remote Management Unit (RMU)
>>> +         binary in the board directory.
>>> +
>>> +config RMU_ADDR
>>> +       hex "Remote Management Unit (RMU) binary location"
>>> +       depends on HAVE_RMU
>>> +       default 0xfff00000
>>> +       help
>>> +         The location of the RMU binary is determined by a strap. It must be
>>> +         put in flash at a location matching the strap-determined base address.
>>> +
>>> +         The default base address of 0xfff00000 indicates that the binary must
>>> +         be located at offset 0 from the beginning of a 1MB flash device.
>>> +
>>> +config HAVE_CMC
>>> +       bool
>>> +       default HAVE_RMU
>>> +
>>> +config CMC_FILE
>>> +       string
>>> +       depends on HAVE_CMC
>>> +       default RMU_FILE
>>> +
>>> +config CMC_ADDR
>>> +       hex
>>> +       depends on HAVE_CMC
>>> +       default RMU_ADDR
>>> +
>>> +config SYS_CAR_ADDR
>>> +       hex
>>> +       default 0x80000000
>>> +
>>> +config SYS_CAR_SIZE
>>> +       hex
>>> +       default 0x8000
>>> +
>>> +endif
>>> diff --git a/arch/x86/cpu/quark/Makefile b/arch/x86/cpu/quark/Makefile
>>> new file mode 100644
>>> index 0000000..168c1e6
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/quark/Makefile
>>> @@ -0,0 +1,8 @@
>>> +#
>>> +# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
>>> +#
>>> +# SPDX-License-Identifier:     GPL-2.0+
>>> +#
>>> +
>>> +obj-y += car.o dram.o msg_port.o quark.o
>>> +obj-$(CONFIG_PCI) += pci.o
>>> diff --git a/arch/x86/cpu/quark/dram.c b/arch/x86/cpu/quark/dram.c
>>> new file mode 100644
>>> index 0000000..fbdc3cd
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/quark/dram.c
>>> @@ -0,0 +1,39 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
>>> + *
>>> + * SPDX-License-Identifier:    GPL-2.0+
>>> + */
>>> +
>>> +#include <common.h>
>>> +#include <asm/post.h>
>>> +#include <asm/arch/quark.h>
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +int dram_init(void)
>>> +{
>>> +       /* hardcode the DRAM size for now */
>>> +       gd->ram_size = DRAM_MAX_SIZE;
>>> +       post_code(POST_DRAM);
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +void dram_init_banksize(void)
>>> +{
>>> +       gd->bd->bi_dram[0].start = 0;
>>> +       gd->bd->bi_dram[0].size = gd->ram_size;
>>> +}
>>> +
>>> +/*
>>> + * This function looks for the highest region of memory lower than 4GB which
>>> + * has enough space for U-Boot where U-Boot is aligned on a page boundary.
>>> + * It overrides the default implementation found elsewhere which simply
>>> + * picks the end of ram, wherever that may be. The location of the stack,
>>> + * the relocation address, and how far U-Boot is moved by relocation are
>>> + * set in the global data structure.
>>> + */
>>> +ulong board_get_usable_ram_top(ulong total_size)
>>> +{
>>> +       return gd->ram_size;
>>> +}
>>> diff --git a/arch/x86/cpu/quark/pci.c b/arch/x86/cpu/quark/pci.c
>>> new file mode 100644
>>> index 0000000..354e15a
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/quark/pci.c
>>> @@ -0,0 +1,70 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
>>> + *
>>> + * SPDX-License-Identifier:    GPL-2.0+
>>> + */
>>> +
>>> +#include <common.h>
>>> +#include <pci.h>
>>> +#include <asm/pci.h>
>>> +#include <asm/arch/device.h>
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +void board_pci_setup_hose(struct pci_controller *hose)
>>> +{
>>> +       hose->first_busno = 0;
>>> +       hose->last_busno = 0;
>>> +
>>> +       /* PCI memory space */
>>> +       pci_set_region(hose->regions + 0,
>>> +                      CONFIG_PCI_MEM_BUS,
>>> +                      CONFIG_PCI_MEM_PHYS,
>>> +                      CONFIG_PCI_MEM_SIZE,
>>> +                      PCI_REGION_MEM);
>>> +
>>> +       /* PCI IO space */
>>> +       pci_set_region(hose->regions + 1,
>>> +                      CONFIG_PCI_IO_BUS,
>>> +                      CONFIG_PCI_IO_PHYS,
>>> +                      CONFIG_PCI_IO_SIZE,
>>> +                      PCI_REGION_IO);
>>> +
>>> +       pci_set_region(hose->regions + 2,
>>> +                      CONFIG_PCI_PREF_BUS,
>>> +                      CONFIG_PCI_PREF_PHYS,
>>> +                      CONFIG_PCI_PREF_SIZE,
>>> +                      PCI_REGION_PREFETCH);
>>> +
>>> +       pci_set_region(hose->regions + 3,
>>> +                      0,
>>> +                      0,
>>> +                      gd->ram_size,
>>> +                      PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
>>> +
>>> +       hose->region_count = 4;
>>> +}
>>> +
>>> +int board_pci_post_scan(struct pci_controller *hose)
>>> +{
>>> +       return 0;
>>> +}
>>> +
>>> +int pci_skip_dev(struct pci_controller *hose, pci_dev_t dev)
>>> +{
>>> +       /*
>>> +        * TODO:
>>> +        *
>>> +        * For some unknown reason, the PCI enumeration process hangs
>>> +        * when it scans to the PCIe root port 0 (D23:F0) & 1 (D23:F1).
>>> +        *
>>> +        * For now we just skip these two devices, and this needs to
>>> +        * be revisited later.
>>> +        */
>>> +       if (dev == QUARK_HOST_BRIDGE ||
>>> +           dev == QUARK_PCIE0 || dev == QUARK_PCIE1) {
>>> +               return 1;
>>
>> BTW I saw a similar thing on Minnowboard Max.
>
> I have not traced this any further. Maybe it is because there is
> nothing connected from any of the PCIe port? I know Freescale PCIe
> controller has such limitation that if there is nothing connected,
> accessing to their register will hang, but Freescale provides a
> register for software to query PCIe link training status which is
> nice.

Maybe. But it seems bad that it doesn't respond.

>
>>> +       }
>>> +
>>> +       return 0;
>>> +}
>>> diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
>>> new file mode 100644
>>> index 0000000..47ba152
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/quark/quark.c
>>> @@ -0,0 +1,44 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
>>> + *
>>> + * SPDX-License-Identifier:    GPL-2.0+
>>> + */
>>> +
>>> +#include <common.h>
>>> +#include <asm/io.h>
>>> +#include <asm/pci.h>
>>> +#include <asm/post.h>
>>> +#include <asm/processor.h>
>>> +
>>> +int arch_cpu_init(void)
>>> +{
>>> +       struct pci_controller *hose;
>>> +       int ret;
>>> +
>>> +       post_code(POST_CPU_INIT);
>>> +#ifdef CONFIG_SYS_X86_TSC_TIMER
>>> +       timer_set_base(rdtsc());
>>> +#endif
>>> +
>>> +       ret = x86_cpu_init_f();
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       ret = pci_early_init_hose(&hose);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +int print_cpuinfo(void)
>>> +{
>>> +       post_code(POST_CPU_INFO);
>>> +       return default_print_cpuinfo();
>>> +}
>>> +
>>> +void reset_cpu(ulong addr)
>>> +{
>>> +       /* cold reset */
>>> +       outb(0x08, PORT_RESET);
>>> +}
>>> diff --git a/arch/x86/include/asm/arch-quark/gpio.h b/arch/x86/include/asm/arch-quark/gpio.h
>>> new file mode 100644
>>> index 0000000..ca8cba4
>>> --- /dev/null
>>> +++ b/arch/x86/include/asm/arch-quark/gpio.h
>>> @@ -0,0 +1,13 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
>>> + *
>>> + * SPDX-License-Identifier:    GPL-2.0+
>>> + */
>>> +
>>> +#ifndef _X86_ARCH_GPIO_H_
>>> +#define _X86_ARCH_GPIO_H_
>>> +
>>> +/* Where in config space is the register that points to the GPIO registers? */
>>> +#define PCI_CFG_GPIOBASE 0x44
>>
>> Should this be in device tree?
>
> I think so, but I think we can leave this change later, just like the
> SPI controller driver?

Yes we don't need to do everything at once. The GPIO side is a bit
broken as you probably saw. I'm really not happen with how I have
implemented it. We should be able to describe the pin mappings in the
device tree.

Regards,
Simon