
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