[U-Boot] [PATCH 2/2] ARM: omap3: evm: Fix distro bootcmd UBIFS and MMC support
The omap3_evm board does not boot when commit:
a47ca2cf67 ("ARM: omap3: evm: Add kernel image loading from UBIFS and EXT4")
is applied after commit:
3dde8f2037 ("Merge git://git.denx.de/u-boot-mmc")
This commit reduces the CONFIG_EXTRA_ENV_SETTINGS size and better
leverages the existing distro bootcmd infrastructure.
- Use updated UBIFS support from config_distro_bootcmd.h
- Use LEGACY_MMC naming found in am335x_evm.h and ti_omap4_common.h
- Remove extra environment content that is no longer needed
[MMC(0:1)/extlinux/extlinux.conf]
---8<---
default omap3-evm-mmc-fat
label omap3-evm-mmc-fat
kernel /zImage
fdt /omap3-evm.dtb
append console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4
rootwait
---8<---
[MMC(0:2)/boot/extlinux/extlinux.conf]
---8<---
default omap3-evm-mmc-ext4
label omap3-evm-mmc-ext4
kernel /boot/zImage
fdt /boot/omap3-evm.dtb
append console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4
rootwait
---8<---
[NAND(ubi0:rootfs)/boot/extlinux/extlinux.conf]
---8<---
default omap3-evm-nand-ubifs
label omap3-evm-nand-ubifs
kernel /boot/zImage
fdt /boot/omap3-evm.dtb
append console=ttyO0,115200n8 root=ubi0:rootfs rw ubi.mtd=rootfs
noinitrd rootfstype=ubifs rootwait
---8<---
Fixes: a47ca2cf67 ("ARM: omap3: evm: Add kernel image loading from UBIFS and
EXT4")
Signed-off-by: Derald D. Woods
---
include/configs/omap3_evm.h | 80 ++---
1 file changed, 25 insertions(+), 55 deletions(-)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 3ecfdbb3ce..c329d97528 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -89,43 +89,24 @@
#define MEM_LAYOUT_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV
-#if defined(CONFIG_NAND) && defined(CONFIG_CMD_UBI)
-/* NAND boot with uImage from NAND 'kernel' partition */
#define BOOTENV_DEV_NAND(devtypeu, devtypel, instance) \
"bootcmd_" #devtypel #instance "=" \
"run nandboot\0"
#define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \
#devtypel #instance " "
-/* NAND boot with zImage from UBIFS '/boot/zImage' */
-#define BOOTENV_DEV_UBIFS_NAND(devtypeu, devtypel, instance) \
+#define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \
"bootcmd_" #devtypel #instance "=" \
- "run nandbootubifs\0"
-#define BOOTENV_DEV_NAME_UBIFS_NAND(devtypeu, devtypel, instance) \
- #devtypel #instance " "
-#endif /* CONFIG_NAND && CONFIG_CMD_UBI */
-
-/* MMC boot with uImage from MMC 0:2 '/boot/uImage' */
-#define BOOTENV_DEV_UIMAGE_MMC(devtypeu, devtypel, instance) \
- "bootcmd_" #devtypel #instance "=" \
- "setenv mmcdev " #instance"; " \
- "run mmcboot\0"
-#define BOOTENV_DEV_NAME_UIMAGE_MMC(devtypeu, devtypel, instance) \
- #devtypel #instance " "
-
-/* MMC boot with zImage from MMC 0:2 '/boot/zImage' */
-#define BOOTENV_DEV_ZIMAGE_MMC(devtypeu, devtypel, instance) \
- "bootcmd_" #devtypel #instance "=" \
- "setenv mmcdev " #instance"; " \
- "run mmcbootz\0"
-#define BOOTENV_DEV_NAME_ZIMAGE_MMC(devtypeu, devtypel, instance) \
+ "setenv mmcdev " #instance "; " \
+ "setenv bootpart " #instance ":${mmcpart} ; " \
+ "run mmcboot\0"
+#define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \
#devtypel #instance " "
#define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
- func(ZIMAGE_MMC, zimage_mmc, 0) \
- func(UIMAGE_MMC, uimage_mmc, 0) \
- func(UBIFS_NAND, ubifs_nand, 0) \
+ func(LEGACY_MMC, legacy_mmc, 0) \
+ func(UBIFS, ubifs, 0) \
func(NAND, nand, 0)
#include
@@ -138,9 +119,13 @@
"fdt_high=0x\0" \
"bootdir=/boot\0" \
"bootenv=uEnv.txt\0" \
+ "bootfile=zImage\0" \
+ "bootubivol=rootfs\0" \
+ "bootubipart=rootfs\0" \
"optargs=\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
+ "bootpart=${mmcdev}:${mmcpart}\0" \
"console=ttyO0,115200n8\0" \
"mmcargs=setenv bootargs console=${console} " \
"${mtdparts} " \
@@ -153,7 +138,7 @@
"root=ubi0:rootfs rw ubi.mtd=rootfs noinitrd " \
"rootfstype=ubifs rootwait\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
- "ext4bootenv=ext4load mmc ${mmcdev}:${mmcpart} ${loadaddr}
${bootdir}/${bootenv}\0" \
+ "ext4bootenv=ext4load mmc ${bootpart} ${loadaddr}
${bootdir}/${bootenv}\0" \
"importbootenv=e
[U-Boot] [PATCH 1/2] distro bootcmd: Allow board defined UBI partition and volume names
This commit allows overriding the default assumption that the boot UBI
MTD partition is named 'UBI' and the UBI volume is 'boot'. A board
desiring to use a legacy or alternative NAND layout can now define the
following two extra environment variables:
bootubipart=
bootubivol=
EXAMPLE:
[include/configs/some_board.h]
---8<---
[...]
#include
#define MEM_LAYOUT_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV
#define BOOT_TARGET_DEVICES(func) \
func(UBIFS, ubifs, 0)
#include
[...]
#define CONFIG_EXTRA_ENV_SETTINGS \
MEM_LAYOUT_ENV_SETTINGS \
"bootubivol=rootfs\0" \
"bootubipart=rootfs\0" \
BOOTENV
[...]
---8<---
Signed-off-by: Derald D. Woods
---
include/config_distro_bootcmd.h | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 5c469a23fa..f567cebd38 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -71,10 +71,15 @@
#ifdef CONFIG_CMD_UBIFS
#define BOOTENV_SHARED_UBIFS \
"ubifs_boot=" \
- "if ubi part UBI && ubifsmount ubi${devnum}:boot; then " \
- "setenv devtype ubi; "\
- "setenv bootpart 0; " \
- "run scan_dev_for_boot; " \
+ "env exists bootubipart || " \
+ "env set bootubipart UBI; " \
+ "env exists bootubivol || " \
+ "env set bootubivol boot; " \
+ "if ubi part ${bootubipart} && " \
+ "ubifsmount ubi${devnum}:${bootubivol}; " \
+ "then " \
+ "setenv devtype ubi; " \
+ "run scan_dev_for_boot; " \
"fi\0"
#define BOOTENV_DEV_UBIFS BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_UBIFS BOOTENV_DEV_NAME_BLKDEV
@@ -125,7 +130,7 @@
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
"if fdt addr ${fdt_addr_r}; then "\
"bootefi ${kernel_addr_r} ${fdt_addr_r};" \
- "else "\
+ "else " \
"bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
"fi\0"\
\
--
2.16.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARM: omap3: evm: Fix distro bootcmd
This series fixes an omap3_evm boot hang on master. It contains a patch to "config_distro_bootcmd.h" which allows board defined UBI partition and volume names. This is used by omap3_evm to eliminate some lines of code. Derald D. Woods (2): distro bootcmd: Allow board defined UBI partition and volume names ARM: omap3: evm: Fix distro bootcmd UBIFS and MMC support include/config_distro_bootcmd.h | 15 +--- include/configs/omap3_evm.h | 80 + 2 files changed, 35 insertions(+), 60 deletions(-) -- 2.16.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] imx: mx7: change sdhc clk to 392M
Hi Fabio > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Sunday, January 21, 2018 4:07 AM > To: Peng Fan > Cc: Stefano Babic ; U-Boot-Denx ; > Fabio Estevam > Subject: Re: [U-Boot] [PATCH 1/5] imx: mx7: change sdhc clk to 392M > > Hi Peng, > > On Fri, Jan 19, 2018 at 7:09 AM, Peng Fan wrote: > > Change sdhc clk to 392M. > > 392 MHz here and in the Subject, please. Thanks for comments. In V2, I think this patch could be droped. 196MHz is enough here. Thanks, Peng. > > > Prepare support for SDR104 and HS200. > > > > Signed-off-by: Peng Fan > > Cc: Stefano Babic > > Cc: Fabio Estevam > > Cc: Jaehoon Chung > > --- > > arch/arm/mach-imx/mx7/clock.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm/mach-imx/mx7/clock.c > > b/arch/arm/mach-imx/mx7/clock.c index c11042d6f5..227037c53d 100644 > > --- a/arch/arm/mach-imx/mx7/clock.c > > +++ b/arch/arm/mach-imx/mx7/clock.c > > @@ -561,17 +561,17 @@ static void init_clk_esdhc(void) > > /* 196: 392/2 */ > > Please remove this line of comment as it is no longer true after this patch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] imx: mx7: change sdhc clk to 392M
Hi Peng, On Fri, Jan 19, 2018 at 7:09 AM, Peng Fan wrote: > Change sdhc clk to 392M. 392 MHz here and in the Subject, please. > Prepare support for SDR104 and HS200. > > Signed-off-by: Peng Fan > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: Jaehoon Chung > --- > arch/arm/mach-imx/mx7/clock.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c > index c11042d6f5..227037c53d 100644 > --- a/arch/arm/mach-imx/mx7/clock.c > +++ b/arch/arm/mach-imx/mx7/clock.c > @@ -561,17 +561,17 @@ static void init_clk_esdhc(void) > /* 196: 392/2 */ Please remove this line of comment as it is no longer true after this patch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: allow creation of more device part nodes
Create device path nodes for UCLASS_ETH udevices.
Create device path nodes of block device children of UCLASS_MMC udevices.
Consistently use debug for unsupported nodes.
Set the log level to error.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 52
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index c941ea7717..7275025b81 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -6,6 +6,8 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#define LOG_CATEGORY LOGL_ERR
+
#include
#include
#include
@@ -111,7 +113,6 @@ int efi_dp_match(const struct efi_device_path *a,
}
}
-
/*
* See UEFI spec (section 3.1.2, about short-form device-paths..
* tl;dr: we can have a device-path that starts with a USB WWID
@@ -184,7 +185,6 @@ static struct efi_object *find_obj(struct efi_device_path
*dp, bool short_path,
return NULL;
}
-
/*
* Find an efiobj from device-path, if 'rem' is not NULL, returns the
* remaining part of the device path after the matched object.
@@ -328,6 +328,9 @@ static unsigned dp_size(struct udevice *dev)
case UCLASS_SIMPLE_BUS:
/* stop traversing parents at this point: */
return sizeof(ROOT);
+ case UCLASS_ETH:
+ return dp_size(dev->parent) +
+ sizeof(struct efi_device_path_mac_addr);
#ifdef CONFIG_BLK
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
@@ -340,14 +343,21 @@ static unsigned dp_size(struct udevice *dev)
case UCLASS_SCSI:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_scsi);
+#endif
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+ case UCLASS_MMC:
+ return dp_size(dev->parent) +
+ sizeof(struct efi_device_path_sd_mmc_path);
#endif
default:
return dp_size(dev->parent);
}
#endif
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
case UCLASS_MMC:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_sd_mmc_path);
+#endif
case UCLASS_MASS_STORAGE:
case UCLASS_USB_HUB:
return dp_size(dev->parent) +
@@ -378,6 +388,21 @@ static void *dp_fill(void *buf, struct udevice *dev)
*vdp = ROOT;
return &vdp[1];
}
+ case UCLASS_ETH: {
+ struct efi_device_path_mac_addr *dp =
+ dp_fill(buf, dev->parent);
+ struct eth_pdata *pdata = dev->platdata;
+
+ dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR;
+ dp->dp.length = sizeof(*dp);
+ memset(&dp->mac, 0, sizeof(dp->mac));
+ /* We only support IPv4 */
+ memcpy(&dp->mac, &pdata->enetaddr, ARP_HLEN);
+ /* Ethernet */
+ dp->if_type = 1;
+ return &dp[1];
+ }
#ifdef CONFIG_BLK
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
@@ -411,10 +436,26 @@ static void *dp_fill(void *buf, struct udevice *dev)
dp->target_id = desc->target;
return &dp[1];
}
+#endif
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+ case UCLASS_MMC: {
+ struct efi_device_path_sd_mmc_path *sddp =
+ dp_fill(buf, dev->parent);
+ struct blk_desc *desc = dev_get_uclass_platdata(dev);
+
+ sddp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ sddp->dp.sub_type = is_sd(desc) ?
+ DEVICE_PATH_SUB_TYPE_MSG_SD :
+ DEVICE_PATH_SUB_TYPE_MSG_MMC;
+ sddp->dp.length = sizeof(*sddp);
+ sddp->slot_number = dev->seq;
+ return &sddp[1];
+ }
#endif
default:
- printf("unhandled parent class: %s (%u)\n",
- dev->name, dev->driver->id);
+ debug("%s(%u) %s: unhandled parent class: %s (%u)\n",
+ __FILE__, __LINE__, __func__,
+ dev->name, dev->parent->uclass->uc_drv->id);
return dp_fill(buf, dev->parent);
}
#endif
@@ -454,7 +495,8 @@ static void *dp_fill(void *buf, struct udevice *dev)
return &udp[1];
}
default:
- debug("unhandled device class: %s (%u)\n",
+ debug("%s(%u) %s: unhandled devic
[U-Boot] [PATCH 1/1] efi_selftest: reduce noise in test output for device trees
Some messages are only useful if an error occurs.
Fix a use after free.
Add a missing free.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_devicepath.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_devicepath.c
b/lib/efi_selftest/efi_selftest_devicepath.c
index 2f8f3c7f15..92940c7ab6 100644
--- a/lib/efi_selftest/efi_selftest_devicepath.c
+++ b/lib/efi_selftest/efi_selftest_devicepath.c
@@ -319,7 +319,6 @@ static int execute(void)
efi_st_error("FreePool failed\n");
return EFI_ST_FAILURE;
}
- efi_st_printf("\n");
/* Test ConvertDevicePathToText */
string = device_path_to_text->convert_device_path_to_text(
@@ -328,15 +327,14 @@ static int execute(void)
efi_st_error("ConvertDevicePathToText failed\n");
return EFI_ST_FAILURE;
}
- efi_st_printf("dp2: %ps\n", string);
if (efi_st_strcmp_16_8(
string,
"/VenHw(dbca4c98-6cb0-694d-0872-819c650cbbb1)/VenHw(dbca4c98-6cb0-694d-0872-819c650cbba2)")
) {
+ efi_st_printf("dp2: %ps\n", string);
efi_st_error("Incorrect text from ConvertDevicePathToText\n");
return EFI_ST_FAILURE;
}
-
ret = boottime->free_pool(string);
if (ret != EFI_SUCCESS) {
efi_st_error("FreePool failed\n");
@@ -350,17 +348,17 @@ static int execute(void)
efi_st_error("ConvertDeviceNodeToText failed\n");
return EFI_ST_FAILURE;
}
- efi_st_printf("dp_node: %ps\n", string);
- ret = boottime->free_pool(string);
- if (ret != EFI_SUCCESS) {
- efi_st_error("FreePool failed\n");
- return EFI_ST_FAILURE;
- }
if (efi_st_strcmp_16_8(string, "u-boot")) {
+ efi_st_printf("dp_node: %ps\n", string);
efi_st_error(
"Incorrect conversion by ConvertDeviceNodeToText\n");
return EFI_ST_FAILURE;
}
+ ret = boottime->free_pool(string);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("FreePool failed\n");
+ return EFI_ST_FAILURE;
+ }
/* Test LocateDevicePath */
remaining_dp = (struct efi_device_path *)dp3;
@@ -380,13 +378,18 @@ static int execute(void)
efi_st_error("ConvertDevicePathToText failed\n");
return EFI_ST_FAILURE;
}
- efi_st_printf("remaining device path: %ps\n", string);
if (efi_st_strcmp_16_8(string,
"/VenHw(dbca4c98-6cb0-694d-0872-819c650cbbc3)")
) {
+ efi_st_printf("remaining device path: %ps\n", string);
efi_st_error("LocateDevicePath: wrong remaining device path\n");
return EFI_ST_FAILURE;
}
+ ret = boottime->free_pool(string);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("FreePool failed\n");
+ return EFI_ST_FAILURE;
+ }
return EFI_ST_SUCCESS;
}
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] dm: ram: bmips: add BCM6318 support
Signed-off-by: Álvaro Fernández Rojas
---
v2: no changes
drivers/ram/bmips_ram.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/ram/bmips_ram.c b/drivers/ram/bmips_ram.c
index 3f9d9a8566..7a5dfac4ab 100644
--- a/drivers/ram/bmips_ram.c
+++ b/drivers/ram/bmips_ram.c
@@ -23,6 +23,8 @@
#define SDRAM_CFG_32B_MASK (1 << SDRAM_CFG_32B_SHIFT)
#define SDRAM_CFG_BANK_SHIFT 13
#define SDRAM_CFG_BANK_MASK(1 << SDRAM_CFG_BANK_SHIFT)
+#define SDRAM_6318_SPACE_SHIFT 4
+#define SDRAM_6318_SPACE_MASK (0xf << SDRAM_6318_SPACE_SHIFT)
#define MEMC_CFG_REG 0x4
#define MEMC_CFG_32B_SHIFT 1
@@ -45,6 +47,16 @@ struct bmips_ram_priv {
const struct bmips_ram_hw *hw;
};
+static ulong bcm6318_get_ram_size(struct bmips_ram_priv *priv)
+{
+ u32 val;
+
+ val = readl_be(priv->regs + SDRAM_CFG_REG);
+ val = (val & SDRAM_6318_SPACE_MASK) >> SDRAM_6318_SPACE_SHIFT;
+
+ return (1 << (val + 20));
+}
+
static ulong bcm6328_get_ram_size(struct bmips_ram_priv *priv)
{
return readl_be(priv->regs + DDR_CSEND_REG) << 24;
@@ -102,6 +114,10 @@ static const struct ram_ops bmips_ram_ops = {
.get_info = bmips_ram_get_info,
};
+static const struct bmips_ram_hw bmips_ram_bcm6318 = {
+ .get_ram_size = bcm6318_get_ram_size,
+};
+
static const struct bmips_ram_hw bmips_ram_bcm6328 = {
.get_ram_size = bcm6328_get_ram_size,
};
@@ -116,6 +132,9 @@ static const struct bmips_ram_hw bmips_ram_bcm6358 = {
static const struct udevice_id bmips_ram_ids[] = {
{
+ .compatible = "brcm,bcm6318-mc",
+ .data = (ulong)&bmips_ram_bcm6318,
+ }, {
.compatible = "brcm,bcm6328-mc",
.data = (ulong)&bmips_ram_bcm6328,
}, {
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] MIPS: add support for Broadcom MIPS BCM6318 SoC family
Signed-off-by: Álvaro Fernández Rojas
---
v2: add missing ngpios
arch/mips/dts/brcm,bcm6318.dtsi| 157 +
arch/mips/mach-bmips/Kconfig | 12 ++
include/configs/bmips_bcm6318.h| 25
include/dt-bindings/clock/bcm6318-clock.h | 37 +
.../power-domain/bcm6318-power-domain.h| 13 ++
include/dt-bindings/reset/bcm6318-reset.h | 26
6 files changed, 270 insertions(+)
create mode 100644 arch/mips/dts/brcm,bcm6318.dtsi
create mode 100644 include/configs/bmips_bcm6318.h
create mode 100644 include/dt-bindings/clock/bcm6318-clock.h
create mode 100644 include/dt-bindings/power-domain/bcm6318-power-domain.h
create mode 100644 include/dt-bindings/reset/bcm6318-reset.h
diff --git a/arch/mips/dts/brcm,bcm6318.dtsi b/arch/mips/dts/brcm,bcm6318.dtsi
new file mode 100644
index 00..54964a7009
--- /dev/null
+++ b/arch/mips/dts/brcm,bcm6318.dtsi
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "brcm,bcm6318";
+
+ aliases {
+ spi0 = &spi;
+ };
+
+ cpus {
+ reg = <0x1000 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
+
+ cpu@0 {
+ compatible = "brcm,bcm6318-cpu", "mips,mips4Kc";
+ device_type = "cpu";
+ reg = <0>;
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ hsspi_pll: hsspi-pll {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000>;
+ };
+
+ periph_osc: periph-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ u-boot,dm-pre-reloc;
+ };
+
+ periph_clk: periph-clk {
+ compatible = "brcm,bcm6345-clk";
+ reg = <0x1004 0x4>;
+ #clock-cells = <1>;
+ };
+ };
+
+ ubus {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ periph_rst: reset-controller@1010 {
+ compatible = "brcm,bcm6345-reset";
+ reg = <0x1010 0x4>;
+ #reset-cells = <1>;
+ };
+
+ wdt: watchdog@1068 {
+ compatible = "brcm,bcm6345-wdt";
+ reg = <0x1068 0xc>;
+ clocks = <&periph_osc>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdt>;
+ };
+
+ pll_cntl: syscon@1074 {
+ compatible = "syscon";
+ reg = <0x1074 0x4>;
+ };
+
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ regmap = <&pll_cntl>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
+
+ gpio1: gpio-controller@1080 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1080 0x4>, <0x1088 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <18>;
+
+ status = "disabled";
+ };
+
+ gpio0: gpio-controller@1084 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1084 0x4>, <0x108c 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ status = "disabled";
+ };
+
+ uart0: serial@1100 {
+ compatible = "brcm,bcm6345-uart";
+ reg = <0x1100 0x18>;
+ clocks = <&periph_osc>;
+
+ status = "disabled";
+ };
+
+ leds: led-controller@1200 {
+ compatible = "brcm,bcm6328-leds";
+ reg = <0x1200 0x28>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
+ periph_pwr:
[U-Boot] [PATCH v2 1/4] dm: cpu: bmips: add BCM6318 support
Signed-off-by: Álvaro Fernández Rojas
---
v2: fix bcm6318 typo
drivers/cpu/bmips_cpu.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/cpu/bmips_cpu.c b/drivers/cpu/bmips_cpu.c
index 2e3f1de74e..4ad291a56e 100644
--- a/drivers/cpu/bmips_cpu.c
+++ b/drivers/cpu/bmips_cpu.c
@@ -26,6 +26,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define REG_BCM6328_OTP0x62c
#define BCM6328_TP1_DISABLED BIT(9)
+#define REG_BCM6318_STRAP_OVRDBUS 0x900
+#define OVRDBUS_6318_FREQ_SHIFT23
+#define OVRDBUS_6318_FREQ_MASK (0x3 << OVRDBUS_6318_FREQ_SHIFT)
+
#define REG_BCM6328_MISC_STRAPBUS 0x1a40
#define STRAPBUS_6328_FCVO_SHIFT 7
#define STRAPBUS_6328_FCVO_MASK(0x1f <<
STRAPBUS_6328_FCVO_SHIFT)
@@ -112,6 +116,28 @@ static ulong bcm3380_get_cpu_freq(struct bmips_cpu_priv
*priv)
return 33300;
}
+static ulong bcm6318_get_cpu_freq(struct bmips_cpu_priv *priv)
+{
+ unsigned int mips_pll_fcvo;
+
+ mips_pll_fcvo = readl_be(priv->regs + REG_BCM6318_STRAP_OVRDBUS);
+ mips_pll_fcvo = (mips_pll_fcvo & OVRDBUS_6318_FREQ_MASK)
+ >> OVRDBUS_6318_FREQ_SHIFT;
+
+ switch (mips_pll_fcvo) {
+ case 0:
+ return 16600;
+ case 1:
+ return 4;
+ case 2:
+ return 25000;
+ case 3:
+ return 33300;
+ default:
+ return 0;
+ }
+}
+
static ulong bcm6328_get_cpu_freq(struct bmips_cpu_priv *priv)
{
unsigned int mips_pll_fcvo;
@@ -233,6 +259,12 @@ static const struct bmips_cpu_hw bmips_cpu_bcm3380 = {
.get_cpu_count = bcm6358_get_cpu_count,
};
+static const struct bmips_cpu_hw bmips_cpu_bcm6318 = {
+ .get_cpu_desc = bmips_short_cpu_desc,
+ .get_cpu_freq = bcm6318_get_cpu_freq,
+ .get_cpu_count = bcm6345_get_cpu_count,
+};
+
static const struct bmips_cpu_hw bmips_cpu_bcm6328 = {
.get_cpu_desc = bmips_long_cpu_desc,
.get_cpu_freq = bcm6328_get_cpu_freq,
@@ -348,6 +380,9 @@ static const struct udevice_id bmips_cpu_ids[] = {
.compatible = "brcm,bcm3380-cpu",
.data = (ulong)&bmips_cpu_bcm3380,
}, {
+ .compatible = "brcm,bcm6318-cpu",
+ .data = (ulong)&bmips_cpu_bcm6318,
+ }, {
.compatible = "brcm,bcm6328-cpu",
.data = (ulong)&bmips_cpu_bcm6328,
}, {
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] MIPS: add BMIPS Comtrend AR-5315u board
Signed-off-by: Álvaro Fernández Rojas
---
v2: no changes
arch/mips/dts/Makefile | 1 +
arch/mips/dts/comtrend,ar-5315u.dts| 85 ++
arch/mips/mach-bmips/Kconfig | 12 +
board/comtrend/ar5315u/Kconfig | 12 +
board/comtrend/ar5315u/MAINTAINERS | 6 +++
board/comtrend/ar5315u/Makefile| 5 ++
board/comtrend/ar5315u/ar-5315u.c | 7 +++
configs/comtrend_ar5315u_ram_defconfig | 51
include/configs/comtrend_ar5315u.h | 16 +++
9 files changed, 195 insertions(+)
create mode 100644 arch/mips/dts/comtrend,ar-5315u.dts
create mode 100644 board/comtrend/ar5315u/Kconfig
create mode 100644 board/comtrend/ar5315u/MAINTAINERS
create mode 100644 board/comtrend/ar5315u/Makefile
create mode 100644 board/comtrend/ar5315u/ar-5315u.c
create mode 100644 configs/comtrend_ar5315u_ram_defconfig
create mode 100644 include/configs/comtrend_ar5315u.h
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 72848ed1b4..840dbf170d 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
dtb-$(CONFIG_TARGET_XILFPGA) += nexys4ddr.dtb
+dtb-$(CONFIG_BOARD_COMTREND_AR5315U) += comtrend,ar-5315u.dtb
dtb-$(CONFIG_BOARD_COMTREND_AR5387UN) += comtrend,ar-5387un.dtb
dtb-$(CONFIG_BOARD_COMTREND_CT5361) += comtrend,ct-5361.dtb
dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += comtrend,vr-3032u.dtb
diff --git a/arch/mips/dts/comtrend,ar-5315u.dts
b/arch/mips/dts/comtrend,ar-5315u.dts
new file mode 100644
index 00..4e4d69b638
--- /dev/null
+++ b/arch/mips/dts/comtrend,ar-5315u.dts
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "brcm,bcm6318.dtsi"
+
+/ {
+ model = "Comtrend AR-5315u";
+ compatible = "comtrend,ar5315-un", "brcm,bcm6318";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&leds {
+ status = "okay";
+
+ led@0 {
+ reg = <0>;
+ active-low;
+ label = "AR-5315u:green:wps";
+ };
+
+ led@1 {
+ reg = <1>;
+ active-low;
+ label = "AR-5315u:green:power";
+ };
+
+ led@2 {
+ reg = <2>;
+ active-low;
+ label = "AR-5315u:green:usb";
+ };
+
+ led@8 {
+ reg = <8>;
+ active-low;
+ label = "AR-5315u:green:inet";
+ };
+
+ led@9 {
+ reg = <9>;
+ active-low;
+ label = "AR-5315u:red:inet";
+ };
+
+ led@10 {
+ reg = <10>;
+ active-low;
+ label = "AR-5315u:green:dsl";
+ };
+
+ led@11 {
+ reg = <11>;
+ active-low;
+ label = "AR-5315u:red:power";
+ };
+};
+
+&spi {
+ status = "okay";
+
+ spi-flash@0 {
+ compatible = "spi-flash";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <6250>;
+ };
+};
+
+&uart0 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/arch/mips/mach-bmips/Kconfig b/arch/mips/mach-bmips/Kconfig
index c9b56f5ca7..e4a0118368 100644
--- a/arch/mips/mach-bmips/Kconfig
+++ b/arch/mips/mach-bmips/Kconfig
@@ -111,6 +111,17 @@ endchoice
choice
prompt "Board select"
+config BOARD_COMTREND_AR5315U
+ bool "Comtrend AR-5315u"
+ depends on SOC_BMIPS_BCM6318
+ select BMIPS_SUPPORTS_BOOT_RAM
+ help
+ Comtrend AR-5315u boards have a BCM6318 SoC with 64 MB of RAM and 16
+ MB of flash (SPI).
+ Between its different peripherals there's an integrated switch with 4
+ ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
+ a BCM43217 (PCIe).
+
config BOARD_COMTREND_AR5387UN
bool "Comtrend AR-5387un"
depends on SOC_BMIPS_BCM6328
@@ -217,6 +228,7 @@ endchoice
config BMIPS_SUPPORTS_BOOT_RAM
bool
+source "board/comtrend/ar5315u/Kconfig"
source "board/comtrend/ar5387un/Kconfig"
source "board/comtrend/ct5361/Kconfig"
source "board/comtrend/vr3032u/Kconfig"
diff --git a/board/comtrend/ar5315u/Kconfig b/board/comtrend/ar5315u/Kconfig
new file mode 100644
index 00..4baae40009
--- /dev/null
+++ b/board/comtrend/ar5315u/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_COMTREND_AR5315U
+
+config SYS_BOARD
+ default "ar5315u"
+
+config SYS_VENDOR
+ default "comtrend"
+
+config SYS_CONFIG_NAME
+ default "comtrend_ar5315u"
+
+endif
diff --git a/board/comtrend/ar5315u/MAINTAINERS
b/board/comtrend/ar5315u/MAINTAINERS
n
[U-Boot] [PATCH v2 0/4] mips: bmips: add BCM6318 SoC support
BCM6318 is a single core BCM63xx SoC. v2: fix bcm6328 typo and add missing ngpios Álvaro Fernández Rojas (4): dm: cpu: bmips: add BCM6318 support dm: ram: bmips: add BCM6318 support MIPS: add support for Broadcom MIPS BCM6318 SoC family MIPS: add BMIPS Comtrend AR-5315u board arch/mips/dts/Makefile | 1 + arch/mips/dts/brcm,bcm6318.dtsi| 157 + arch/mips/dts/comtrend,ar-5315u.dts| 85 +++ arch/mips/mach-bmips/Kconfig | 24 board/comtrend/ar5315u/Kconfig | 12 ++ board/comtrend/ar5315u/MAINTAINERS | 6 + board/comtrend/ar5315u/Makefile| 5 + board/comtrend/ar5315u/ar-5315u.c | 7 + configs/comtrend_ar5315u_ram_defconfig | 51 +++ drivers/cpu/bmips_cpu.c| 35 + drivers/ram/bmips_ram.c| 19 +++ include/configs/bmips_bcm6318.h| 25 include/configs/comtrend_ar5315u.h | 16 +++ include/dt-bindings/clock/bcm6318-clock.h | 37 + .../power-domain/bcm6318-power-domain.h| 13 ++ include/dt-bindings/reset/bcm6318-reset.h | 26 16 files changed, 519 insertions(+) create mode 100644 arch/mips/dts/brcm,bcm6318.dtsi create mode 100644 arch/mips/dts/comtrend,ar-5315u.dts create mode 100644 board/comtrend/ar5315u/Kconfig create mode 100644 board/comtrend/ar5315u/MAINTAINERS create mode 100644 board/comtrend/ar5315u/Makefile create mode 100644 board/comtrend/ar5315u/ar-5315u.c create mode 100644 configs/comtrend_ar5315u_ram_defconfig create mode 100644 include/configs/bmips_bcm6318.h create mode 100644 include/configs/comtrend_ar5315u.h create mode 100644 include/dt-bindings/clock/bcm6318-clock.h create mode 100644 include/dt-bindings/power-domain/bcm6318-power-domain.h create mode 100644 include/dt-bindings/reset/bcm6318-reset.h -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] log: add category LOGC_EFI
The EFI implementation does not fit into any of the existing categories.
Provide LOGC_EFI so that EFI related message can be filtered.
Signed-off-by: Heinrich Schuchardt
---
doc/README.log | 1 +
include/log.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/doc/README.log b/doc/README.log
index f653fe7d79..be9978a270 100644
--- a/doc/README.log
+++ b/doc/README.log
@@ -51,6 +51,7 @@ The following main categories are defined:
LOGC_BOARD - Related to board-specific code
LOGC_CORE - Related to core driver-model support
LOGC_DT - Related to device tree control
+ LOGC_EFI- Related to the EFI implementation
Enabling logging
diff --git a/include/log.h b/include/log.h
index 8083b64831..b155725de0 100644
--- a/include/log.h
+++ b/include/log.h
@@ -43,6 +43,7 @@ enum log_category_t {
LOGC_BOARD,
LOGC_CORE,
LOGC_DT,
+ LOGC_EFI,
LOGC_COUNT,
LOGC_END,
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master
On Sat, Jan 20, 2018 at 10:01:20AM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the following patches for the Marvell A38x DDR > code from Chris. > > Thanks, > Stefan > > > The following changes since commit 086ebcd40e9bf8efc520f1b177fd8e3cc0e506fa: > > Merge git://git.denx.de/u-boot-fsl-qoriq (2018-01-17 13:48:35 -0500) > > are available in the Git repository at: > > git://www.denx.de/git/u-boot-marvell.git > > for you to fetch changes up to 672e5598301b63f95d7dcceb4436f3cb40643f88: > > ddr: marvell: update ddr controller init and freq (2018-01-19 16:30:29 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] serial: sh: Add support for R7S72100 (RZ/A1)
On 01/20/2018 04:15 PM, Chris Brandt wrote: > On Friday, January 19, 2018 1, Marek Vasut wrote: >> I wonder if we really cannot get to the point where we can have a >> universal build, add DT to it and be done with a board port. That'd be >> real cool and it'd make things easy for people using the chip ... :) > > Then I'd be out of a job! > > ;) > You can still write the DTs ;-) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] serial: sh: Add support for R7S72100 (RZ/A1)
On Friday, January 19, 2018 1, Marek Vasut wrote: > I wonder if we really cannot get to the point where we can have a > universal build, add DT to it and be done with a board port. That'd be > real cool and it'd make things easy for people using the chip ... :) Then I'd be out of a job! ;) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-boot can verify an HW signature?
Hi Saveiro, 2018-01-19 16:45 GMT-02:00 Saverio Mori : > Hi Breno Lima, > For the moment we have not secure boot, we use "plain" u-boot running on > a module board equipped with an "open" i.MX6UL processor, and we are > newbies in the field of secure boot. We wish that our firmware works > only on approved hardware, and not on common one. From what we have > read, secured boot allow that only approved FW works on prepared HW; our > problem is just the reciprocal, i.e. allow running of our FW only on > approved boards. In other words, a secured FW can works on a unsecured > board (while a secured board requires a secured FW), we wish to block > this situation. > All The Best, You can have more details about secure boot in doc/README.mxc_hab file. The application note AN4581 can be also helpful: https://www.nxp.com/docs/en/application-note/AN4581.pdf The secure boot is intended to prepare your device to just run authenticated SW, once your SRK Hash and SEC_CONFIG fuse are programmed you can only execute authenticated bootloader on this device. If you want that your SW can be only executed on approved hardware you can refer to encrypted boot, which is supported on i.MX6UL. You can find more details in doc/README.mxc_hab file and also in NXP community. Currently there is no application note provided by NXP about encrypted boot: https://community.nxp.com/docs/DOC-330622 Note that dek_blob command can be only executed in closed devices, so you need to run an authenticated U-Boot to prepare an encrypted boot image. Let us know if you have any questions during the process. Thanks, Breno Lima > > Saverio M. > > Il 19/01/2018 18:54, Breno Matheus Lima ha scritto: >> Hi Saverio, >> >> 2018-01-19 11:12 GMT-02:00 Saverio Mori : >>> Hi to the community. I have found a lot of material on secure booting and >>> how to sign u-boot an uimage in order to that only trusted sw is load. This >>> is good for my but i have also the opposite problem, that is i have to be >>> sure that my sw is load on an hardware signed in some way. It is possible, >>> and how, implement this feature in u-boot, at least running on iMX6 boards? >>> Thanks!!! >> Can you please share more details about this verification you want to >> achieve? Are you currently running a signed U-Boot in a closed device >> (eFuse SEC_CONFIG = 1)? >> >> Thanks, >> Breno Lima > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] SPL: allow fall-back to SDP boot
When SDP is enabled, allow it to be invoked as a fall-back
to allow re-programming a board with a full U-Boot loaded
over USB.
Signed-off-by: Eric Nelson
---
Since SDP loading is triggered through BOOT_DEVICE_BOARD, I'm not sure
if this should be specific to SDP.
common/spl/spl.c | 12
1 file changed, 12 insertions(+)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963..5bbd4ed 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -373,6 +373,9 @@ static int boot_from_devices(struct spl_image_info
*spl_image,
void board_init_r(gd_t *dummy1, ulong dummy2)
{
+#ifdef CONFIG_SPL_USB_SDP_SUPPORT
+ int i;
+#endif
u32 spl_boot_list[] = {
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
@@ -417,6 +420,15 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
#endif
board_boot_order(spl_boot_list);
+#ifdef CONFIG_SPL_USB_SDP_SUPPORT
+ for (i = 0; i < ARRAY_SIZE(spl_boot_list); i++) {
+ if (spl_boot_list[i] == BOOT_DEVICE_NONE) {
+ spl_boot_list[i] = BOOT_DEVICE_BOARD;
+ break;
+ }
+ }
+#endif
+
if (boot_from_devices(&spl_image, spl_boot_list,
ARRAY_SIZE(spl_boot_list))) {
puts("SPL: failed to boot from all boot devices\n");
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router
Hi On 20 January 2018 10:07:57 CET, Stefan Roese wrote: >Hi Andreas, > >On 20.01.2018 03:30, Andreas Färber wrote: >> Am 20.01.2018 um 02:40 schrieb Andreas Färber: >>> Hi, >>> >>> Am 18.01.2018 um 18:20 schrieb Stefan Roese: On 17.01.2018 16:52, Andreas Färber wrote: > Am 09.06.2017 um 19:28 schrieb Marek Behún: >> This is the fourth version of patches for adding support for the >> Turris Omnia board, a router developed by the CZ.NIC. > > I'm still facing trouble testing turris_omnia on latest v2018.01. > > First, that made me notice there's no README for how to test and >deploy. > I'm aware of temporary: > sendbeacon /dev/ttyUSBx I have to admit, that don't know anything about this "sendbeacon" tool. > ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p This is what I have used, when I tested / debugged images for Armada XP / 38x. Please note that the init sequence is somewhat "fragile" - so I added the -q and -s parameters, to optionally finetune the startup timings: # kwboot ... -q : use specific request-delay -s : use specific response-timeout You might what to play a bit with these parameters as well. >>> >>> I saw them but had no idea what to pass as values. ;) >>> I did try -a, but it worked with and without. >>> BTW: I don't have access to the Omnia router, so I can't test anything on this specific platform. BTW2: Kosta from Marvell just recently added a new tool / script, to help debug / boot Marvell MVEBU boards: tools/mrvl_uart.sh He told me that its better to use than the "old" kwboot tool. I never found the time to use it up until now, so I have no personal experience. But I'm pretty sure that Kosta did a great job here. So please give it a try. >>> >>> I did not get it to work ... or was not patient enough. >>> > # or without -p when s/BOOT_FROM spi/BOOT_FROM uart/ > and permanent: > tftpboot 0x100 u-boot-spl.kwb > sf probe > sf update 0x100 0 $filesize > > I used to have the original factory CZ.NIC U-Boot in SPI and >booted test > versions only via sendbeacon+kwboot. > > With mainline that appears to be broken - the CONFIG_ARMADA_38X >code in > arch/arm/mach-mvebu/spl.c seems to run into !boot_device and >instead of > UART tries to boot from SPI - nothing happens then and kwboot >complains. > I can force it to continue booting from UART by commenting out the >if. > So Stefan, it looks like your auto-detection is not working here >and the > Kconfig option to force it was dropped prematurely. Hmmm. Then some patch must have broken this UART boot-ability. >Could you by any chance git-bisect, to check which patch broke this functionality? Perhaps some of the newer patches from Sean >Nyekjaer? >>> >>> I've so far found that v2017.11 had UART boot working okay. >> >> git-bisect pointed to this commit: >> >> e83e2b390038c9075642cb243a6292241beb8d73 is the first bad commit >> commit e83e2b390038c9075642cb243a6292241beb8d73 >> Author: Sean Nyekjaer >> Date: Fri Nov 24 14:01:28 2017 +0100 >> >> arm: mvebu: fix boot from UART when in fallback mode >> >> It's the first 8 bits of the bootrom error register that >> contain the boot error/fallback error code. Let's check that >> and continue to boot from UART. >> >> Signed-off-by: Sean Nyekjaer >> Signed-off-by: Stefan Roese >> >> :04 04 c4c5cb4287ae8c3ced749a9734213a5844ddf1d9 >> 772ec1e6401cbb2616b1337ff8757b72240458b3 M arch > >Many thanks for digging into this. I'll try to check UART booting >with a A38x board sometime next week. Perhaps Sean already has >some ideas in the meantime... What device are the Omnia booting from? I was fixing when booting from uart when the romloader does fallback from other devices. What value does boot_device contain? BR Sean > >Thanks, >Stefan > >> Regards, >> Andreas >> > When forcing UART, as soon as the progress surpasses 99%, it >reboots > into SPI SPL without any error message. > Using the old U-Boot fork I've tried flashing u-boot-spl.kwb - >similarly > it gets stuck in the SPL trying to boot on from SPI. After a while >it > reboots, and so on in a loop. > > So it seems that non-SPL U-Boot 2018.01 is broken, on my 2 GB >model. Hmmm. I can only >>> >>> I have reconfirmed (with our GCC 7.2.1) that no version works for >me: >>> >>> v2017.07 did not have turris_omnia defconfig yet >>> b6ee860b87d8accedfb7a1fd5414f7c483603234 bad (adds turris_omnia) >>> v2017.09 bad >>> v2017.11 bad >>> v2018.01 bad >>> master bad (c4cb6e64bf068eaa1f7c96cb37da7ae6d40bbbff / arc merge) >>> >>> So I have nothing to bisect and wonder how Marek tested this... >>> > I also ran into a couple DDR3 training failures when booting via >UART. > No such training
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On Sat, Jan 20, 2018 at 11:31:19AM +, Marc Zyngier wrote: > Define enough. These patches allow these CPUs to cope with variant-2, > and only variant-2. Variant-1 is still work in progress across all > architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM > implementations, and only A15 is susceptible to variant-3a. I think you need to be really careful about statements like this. As you know, it is possible to run a 32bit environment in a VM on the 64bit CPUs. So, its entirely possible to run a 32bit setup on a Cortex A72 for example, and that means such a setup _is_ vulnerable to variant 3a. Do people do this? That isn't something we can really know, but I think as long as its allowed, you can bet that someone will, and someone will end up using it in a production environment. So, it can't be ignored. -- Russell King ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fs: btrfs: Fix unaligned memory accesses
Loading files stored with lzo compression from a btrfs filesystem was
producing unaligned memory accesses, which were causing a data abort
and a reset on an Orange Pi Zero.
The change in hash.c is not triggered by any error but follows the
same pattern. Please confirm.
Fixed according to doc/README.unaligned-memory-access.txt
Signed-off by: Alberto Sánchez Molero
---
fs/btrfs/compression.c | 5 +++--
fs/btrfs/hash.c| 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index a59ff5a..4e685a0 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -9,6 +9,7 @@
#include "btrfs.h"
#include
#include
+#include
static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8 *dbuf, u32 dlen)
{
@@ -19,7 +20,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen,
u8 *dbuf, u32 dlen)
if (clen < 4)
return -1;
-tot_len = le32_to_cpu(*(u32 *) cbuf);
+tot_len = le32_to_cpu(get_unaligned((u32 *) cbuf));
cbuf += 4;
clen -= 4;
tot_len -= 4;
@@ -32,7 +33,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen,
u8 *dbuf, u32 dlen)
res = 0;
while (tot_len > 4) {
-in_len = le32_to_cpu(*(u32 *) cbuf);
+in_len = le32_to_cpu(get_unaligned((u32 *) cbuf));
cbuf += 4;
clen -= 4;
diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
index f8a50e5..1c75ea8 100644
--- a/fs/btrfs/hash.c
+++ b/fs/btrfs/hash.c
@@ -8,6 +8,7 @@
#include "btrfs.h"
#include
+#include
static u32 btrfs_crc32c_table[256];
@@ -34,5 +35,5 @@ u32 btrfs_csum_data(char *data, u32 seed, size_t len)
void btrfs_csum_final(u32 crc, void *result)
{
-*((u32 *) result) = cpu_to_le32(~crc);
+put_unaligned(cpu_to_le32(~crc), (u32 *) result);
}
--
2.16.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: xhci: Fix bool initialization in xhci_bulk_tx
Bool initializations should use true and false.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Cc: Bin Meng
Cc: Marek Vasut
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 579e670..7599c91 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -557,7 +557,7 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
- bool first_trb = 0;
+ bool first_trb = false;
int start_cycle;
u32 field = 0;
u32 length_field = 0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] dm: ram: bmips: add BCM6318 support
Signed-off-by: Álvaro Fernández Rojas
---
drivers/ram/bmips_ram.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/ram/bmips_ram.c b/drivers/ram/bmips_ram.c
index 3f9d9a8566..7a5dfac4ab 100644
--- a/drivers/ram/bmips_ram.c
+++ b/drivers/ram/bmips_ram.c
@@ -23,6 +23,8 @@
#define SDRAM_CFG_32B_MASK (1 << SDRAM_CFG_32B_SHIFT)
#define SDRAM_CFG_BANK_SHIFT 13
#define SDRAM_CFG_BANK_MASK(1 << SDRAM_CFG_BANK_SHIFT)
+#define SDRAM_6318_SPACE_SHIFT 4
+#define SDRAM_6318_SPACE_MASK (0xf << SDRAM_6318_SPACE_SHIFT)
#define MEMC_CFG_REG 0x4
#define MEMC_CFG_32B_SHIFT 1
@@ -45,6 +47,16 @@ struct bmips_ram_priv {
const struct bmips_ram_hw *hw;
};
+static ulong bcm6318_get_ram_size(struct bmips_ram_priv *priv)
+{
+ u32 val;
+
+ val = readl_be(priv->regs + SDRAM_CFG_REG);
+ val = (val & SDRAM_6318_SPACE_MASK) >> SDRAM_6318_SPACE_SHIFT;
+
+ return (1 << (val + 20));
+}
+
static ulong bcm6328_get_ram_size(struct bmips_ram_priv *priv)
{
return readl_be(priv->regs + DDR_CSEND_REG) << 24;
@@ -102,6 +114,10 @@ static const struct ram_ops bmips_ram_ops = {
.get_info = bmips_ram_get_info,
};
+static const struct bmips_ram_hw bmips_ram_bcm6318 = {
+ .get_ram_size = bcm6318_get_ram_size,
+};
+
static const struct bmips_ram_hw bmips_ram_bcm6328 = {
.get_ram_size = bcm6328_get_ram_size,
};
@@ -116,6 +132,9 @@ static const struct bmips_ram_hw bmips_ram_bcm6358 = {
static const struct udevice_id bmips_ram_ids[] = {
{
+ .compatible = "brcm,bcm6318-mc",
+ .data = (ulong)&bmips_ram_bcm6318,
+ }, {
.compatible = "brcm,bcm6328-mc",
.data = (ulong)&bmips_ram_bcm6328,
}, {
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] mips: bmips: add BCM6318 SoC support
BCM6318 is a single core BCM63xx SoC. Álvaro Fernández Rojas (4): dm: cpu: bmips: add BCM6318 support dm: ram: bmips: add BCM6318 support MIPS: add support for Broadcom MIPS BCM6318 SoC family MIPS: add BMIPS Comtrend AR-5315u board arch/mips/dts/Makefile | 1 + arch/mips/dts/brcm,bcm6318.dtsi| 156 + arch/mips/dts/comtrend,ar-5315u.dts| 85 +++ arch/mips/mach-bmips/Kconfig | 24 board/comtrend/ar5315u/Kconfig | 12 ++ board/comtrend/ar5315u/MAINTAINERS | 6 + board/comtrend/ar5315u/Makefile| 5 + board/comtrend/ar5315u/ar-5315u.c | 7 + configs/comtrend_ar5315u_ram_defconfig | 51 +++ drivers/cpu/bmips_cpu.c| 35 + drivers/ram/bmips_ram.c| 19 +++ include/configs/bmips_bcm6318.h| 25 include/configs/comtrend_ar5315u.h | 16 +++ include/dt-bindings/clock/bcm6318-clock.h | 37 + .../power-domain/bcm6318-power-domain.h| 13 ++ include/dt-bindings/reset/bcm6318-reset.h | 26 16 files changed, 518 insertions(+) create mode 100644 arch/mips/dts/brcm,bcm6318.dtsi create mode 100644 arch/mips/dts/comtrend,ar-5315u.dts create mode 100644 board/comtrend/ar5315u/Kconfig create mode 100644 board/comtrend/ar5315u/MAINTAINERS create mode 100644 board/comtrend/ar5315u/Makefile create mode 100644 board/comtrend/ar5315u/ar-5315u.c create mode 100644 configs/comtrend_ar5315u_ram_defconfig create mode 100644 include/configs/bmips_bcm6318.h create mode 100644 include/configs/comtrend_ar5315u.h create mode 100644 include/dt-bindings/clock/bcm6318-clock.h create mode 100644 include/dt-bindings/power-domain/bcm6318-power-domain.h create mode 100644 include/dt-bindings/reset/bcm6318-reset.h -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] MIPS: add BMIPS Comtrend AR-5315u board
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/dts/Makefile | 1 +
arch/mips/dts/comtrend,ar-5315u.dts| 85 ++
arch/mips/mach-bmips/Kconfig | 12 +
board/comtrend/ar5315u/Kconfig | 12 +
board/comtrend/ar5315u/MAINTAINERS | 6 +++
board/comtrend/ar5315u/Makefile| 5 ++
board/comtrend/ar5315u/ar-5315u.c | 7 +++
configs/comtrend_ar5315u_ram_defconfig | 51
include/configs/comtrend_ar5315u.h | 16 +++
9 files changed, 195 insertions(+)
create mode 100644 arch/mips/dts/comtrend,ar-5315u.dts
create mode 100644 board/comtrend/ar5315u/Kconfig
create mode 100644 board/comtrend/ar5315u/MAINTAINERS
create mode 100644 board/comtrend/ar5315u/Makefile
create mode 100644 board/comtrend/ar5315u/ar-5315u.c
create mode 100644 configs/comtrend_ar5315u_ram_defconfig
create mode 100644 include/configs/comtrend_ar5315u.h
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 72848ed1b4..840dbf170d 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
dtb-$(CONFIG_TARGET_XILFPGA) += nexys4ddr.dtb
+dtb-$(CONFIG_BOARD_COMTREND_AR5315U) += comtrend,ar-5315u.dtb
dtb-$(CONFIG_BOARD_COMTREND_AR5387UN) += comtrend,ar-5387un.dtb
dtb-$(CONFIG_BOARD_COMTREND_CT5361) += comtrend,ct-5361.dtb
dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += comtrend,vr-3032u.dtb
diff --git a/arch/mips/dts/comtrend,ar-5315u.dts
b/arch/mips/dts/comtrend,ar-5315u.dts
new file mode 100644
index 00..cdabd87731
--- /dev/null
+++ b/arch/mips/dts/comtrend,ar-5315u.dts
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2017 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "brcm,bcm6318.dtsi"
+
+/ {
+ model = "Comtrend AR-5315u";
+ compatible = "comtrend,ar5315-un", "brcm,bcm6318";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&leds {
+ status = "okay";
+
+ led@0 {
+ reg = <0>;
+ active-low;
+ label = "AR-5315u:green:wps";
+ };
+
+ led@1 {
+ reg = <1>;
+ active-low;
+ label = "AR-5315u:green:power";
+ };
+
+ led@2 {
+ reg = <2>;
+ active-low;
+ label = "AR-5315u:green:usb";
+ };
+
+ led@8 {
+ reg = <8>;
+ active-low;
+ label = "AR-5315u:green:inet";
+ };
+
+ led@9 {
+ reg = <9>;
+ active-low;
+ label = "AR-5315u:red:inet";
+ };
+
+ led@10 {
+ reg = <10>;
+ active-low;
+ label = "AR-5315u:green:dsl";
+ };
+
+ led@11 {
+ reg = <11>;
+ active-low;
+ label = "AR-5315u:red:power";
+ };
+};
+
+&spi {
+ status = "okay";
+
+ spi-flash@0 {
+ compatible = "spi-flash";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <6250>;
+ };
+};
+
+&uart0 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/arch/mips/mach-bmips/Kconfig b/arch/mips/mach-bmips/Kconfig
index c9b56f5ca7..e4a0118368 100644
--- a/arch/mips/mach-bmips/Kconfig
+++ b/arch/mips/mach-bmips/Kconfig
@@ -111,6 +111,17 @@ endchoice
choice
prompt "Board select"
+config BOARD_COMTREND_AR5315U
+ bool "Comtrend AR-5315u"
+ depends on SOC_BMIPS_BCM6318
+ select BMIPS_SUPPORTS_BOOT_RAM
+ help
+ Comtrend AR-5315u boards have a BCM6318 SoC with 64 MB of RAM and 16
+ MB of flash (SPI).
+ Between its different peripherals there's an integrated switch with 4
+ ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
+ a BCM43217 (PCIe).
+
config BOARD_COMTREND_AR5387UN
bool "Comtrend AR-5387un"
depends on SOC_BMIPS_BCM6328
@@ -217,6 +228,7 @@ endchoice
config BMIPS_SUPPORTS_BOOT_RAM
bool
+source "board/comtrend/ar5315u/Kconfig"
source "board/comtrend/ar5387un/Kconfig"
source "board/comtrend/ct5361/Kconfig"
source "board/comtrend/vr3032u/Kconfig"
diff --git a/board/comtrend/ar5315u/Kconfig b/board/comtrend/ar5315u/Kconfig
new file mode 100644
index 00..4baae40009
--- /dev/null
+++ b/board/comtrend/ar5315u/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_COMTREND_AR5315U
+
+config SYS_BOARD
+ default "ar5315u"
+
+config SYS_VENDOR
+ default "comtrend"
+
+config SYS_CONFIG_NAME
+ default "comtrend_ar5315u"
+
+endif
diff --git a/board/comtrend/ar5315u/MAINTAINERS
b/board/comtrend/ar5315u/MAINTAINERS
new file mode 1006
[U-Boot] [PATCH 3/4] MIPS: add support for Broadcom MIPS BCM6318 SoC family
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/dts/brcm,bcm6318.dtsi| 156 +
arch/mips/mach-bmips/Kconfig | 12 ++
include/configs/bmips_bcm6318.h| 25
include/dt-bindings/clock/bcm6318-clock.h | 37 +
.../power-domain/bcm6318-power-domain.h| 13 ++
include/dt-bindings/reset/bcm6318-reset.h | 26
6 files changed, 269 insertions(+)
create mode 100644 arch/mips/dts/brcm,bcm6318.dtsi
create mode 100644 include/configs/bmips_bcm6318.h
create mode 100644 include/dt-bindings/clock/bcm6318-clock.h
create mode 100644 include/dt-bindings/power-domain/bcm6318-power-domain.h
create mode 100644 include/dt-bindings/reset/bcm6318-reset.h
diff --git a/arch/mips/dts/brcm,bcm6318.dtsi b/arch/mips/dts/brcm,bcm6318.dtsi
new file mode 100644
index 00..d501a9410a
--- /dev/null
+++ b/arch/mips/dts/brcm,bcm6318.dtsi
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "brcm,bcm6318";
+
+ aliases {
+ spi0 = &spi;
+ };
+
+ cpus {
+ reg = <0x1000 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
+
+ cpu@0 {
+ compatible = "brcm,bcm6318-cpu", "mips,mips4Kc";
+ device_type = "cpu";
+ reg = <0>;
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ hsspi_pll: hsspi-pll {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000>;
+ };
+
+ periph_osc: periph-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ u-boot,dm-pre-reloc;
+ };
+
+ periph_clk: periph-clk {
+ compatible = "brcm,bcm6345-clk";
+ reg = <0x1004 0x4>;
+ #clock-cells = <1>;
+ };
+ };
+
+ ubus {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ periph_rst: reset-controller@1010 {
+ compatible = "brcm,bcm6345-reset";
+ reg = <0x1010 0x4>;
+ #reset-cells = <1>;
+ };
+
+ wdt: watchdog@1068 {
+ compatible = "brcm,bcm6345-wdt";
+ reg = <0x1068 0xc>;
+ clocks = <&periph_osc>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdt>;
+ };
+
+ pll_cntl: syscon@1074 {
+ compatible = "syscon";
+ reg = <0x1074 0x4>;
+ };
+
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ regmap = <&pll_cntl>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
+
+ gpio1: gpio-controller@1080 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1080 0x4>, <0x1088 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ status = "disabled";
+ };
+
+ gpio0: gpio-controller@1084 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1084 0x4>, <0x108c 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ status = "disabled";
+ };
+
+ uart0: serial@1100 {
+ compatible = "brcm,bcm6345-uart";
+ reg = <0x1100 0x18>;
+ clocks = <&periph_osc>;
+
+ status = "disabled";
+ };
+
+ leds: led-controller@1200 {
+ compatible = "brcm,bcm6328-leds";
+ reg = <0x1200 0x28>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
+ periph_pwr: power-controller@18e8 {
+ compatible
[U-Boot] [PATCH 1/4] dm: cpu: bmips: add BCM6318 support
Signed-off-by: Álvaro Fernández Rojas
---
drivers/cpu/bmips_cpu.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/cpu/bmips_cpu.c b/drivers/cpu/bmips_cpu.c
index 2e3f1de74e..1fe5d106d0 100644
--- a/drivers/cpu/bmips_cpu.c
+++ b/drivers/cpu/bmips_cpu.c
@@ -26,6 +26,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define REG_BCM6328_OTP0x62c
#define BCM6328_TP1_DISABLED BIT(9)
+#define REG_BCM6328_STRAP_OVRDBUS 0x900
+#define OVRDBUS_6318_FREQ_SHIFT23
+#define OVRDBUS_6318_FREQ_MASK (0x3 << OVRDBUS_6318_FREQ_SHIFT)
+
#define REG_BCM6328_MISC_STRAPBUS 0x1a40
#define STRAPBUS_6328_FCVO_SHIFT 7
#define STRAPBUS_6328_FCVO_MASK(0x1f <<
STRAPBUS_6328_FCVO_SHIFT)
@@ -112,6 +116,28 @@ static ulong bcm3380_get_cpu_freq(struct bmips_cpu_priv
*priv)
return 33300;
}
+static ulong bcm6318_get_cpu_freq(struct bmips_cpu_priv *priv)
+{
+ unsigned int mips_pll_fcvo;
+
+ mips_pll_fcvo = readl_be(priv->regs + REG_BCM6328_STRAP_OVRDBUS);
+ mips_pll_fcvo = (mips_pll_fcvo & OVRDBUS_6318_FREQ_MASK)
+ >> OVRDBUS_6318_FREQ_SHIFT;
+
+ switch (mips_pll_fcvo) {
+ case 0:
+ return 16600;
+ case 1:
+ return 4;
+ case 2:
+ return 25000;
+ case 3:
+ return 33300;
+ default:
+ return 0;
+ }
+}
+
static ulong bcm6328_get_cpu_freq(struct bmips_cpu_priv *priv)
{
unsigned int mips_pll_fcvo;
@@ -233,6 +259,12 @@ static const struct bmips_cpu_hw bmips_cpu_bcm3380 = {
.get_cpu_count = bcm6358_get_cpu_count,
};
+static const struct bmips_cpu_hw bmips_cpu_bcm6318 = {
+ .get_cpu_desc = bmips_short_cpu_desc,
+ .get_cpu_freq = bcm6318_get_cpu_freq,
+ .get_cpu_count = bcm6345_get_cpu_count,
+};
+
static const struct bmips_cpu_hw bmips_cpu_bcm6328 = {
.get_cpu_desc = bmips_long_cpu_desc,
.get_cpu_freq = bcm6328_get_cpu_freq,
@@ -348,6 +380,9 @@ static const struct udevice_id bmips_cpu_ids[] = {
.compatible = "brcm,bcm3380-cpu",
.data = (ulong)&bmips_cpu_bcm3380,
}, {
+ .compatible = "brcm,bcm6318-cpu",
+ .data = (ulong)&bmips_cpu_bcm6318,
+ }, {
.compatible = "brcm,bcm6328-cpu",
.data = (ulong)&bmips_cpu_bcm6328,
}, {
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] MIPS: add BMIPS Comtrend WAP-5813n board
Signed-off-by: Álvaro Fernández Rojas
---
v2: Add board Kconfig and clean defconfig
arch/mips/dts/Makefile | 1 +
arch/mips/dts/comtrend,wap-5813n.dts| 65 +
arch/mips/mach-bmips/Kconfig| 12 ++
board/comtrend/wap5813n/Kconfig | 12 ++
board/comtrend/wap5813n/MAINTAINERS | 6 +++
board/comtrend/wap5813n/Makefile| 5 +++
board/comtrend/wap5813n/wap-5813n.c | 7
configs/comtrend_wap5813n_ram_defconfig | 43 ++
include/configs/comtrend_wap5813n.h | 19 ++
9 files changed, 170 insertions(+)
create mode 100644 arch/mips/dts/comtrend,wap-5813n.dts
create mode 100644 board/comtrend/wap5813n/Kconfig
create mode 100644 board/comtrend/wap5813n/MAINTAINERS
create mode 100644 board/comtrend/wap5813n/Makefile
create mode 100644 board/comtrend/wap5813n/wap-5813n.c
create mode 100644 configs/comtrend_wap5813n_ram_defconfig
create mode 100644 include/configs/comtrend_wap5813n.h
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index a190485ded..72848ed1b4 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -11,6 +11,7 @@ dtb-$(CONFIG_TARGET_XILFPGA) += nexys4ddr.dtb
dtb-$(CONFIG_BOARD_COMTREND_AR5387UN) += comtrend,ar-5387un.dtb
dtb-$(CONFIG_BOARD_COMTREND_CT5361) += comtrend,ct-5361.dtb
dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += comtrend,vr-3032u.dtb
+dtb-$(CONFIG_BOARD_COMTREND_WAP5813N) += comtrend,wap-5813n.dtb
dtb-$(CONFIG_BOARD_HUAWEI_HG556A) += huawei,hg556a.dtb
dtb-$(CONFIG_BOARD_NETGEAR_CG3100D) += netgear,cg3100d.dtb
dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
diff --git a/arch/mips/dts/comtrend,wap-5813n.dts
b/arch/mips/dts/comtrend,wap-5813n.dts
new file mode 100644
index 00..29386e2662
--- /dev/null
+++ b/arch/mips/dts/comtrend,wap-5813n.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2017 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "brcm,bcm6368.dtsi"
+
+/ {
+ model = "Comtrend WAP-5813n";
+ compatible = "comtrend,wap-5813n", "brcm,bcm6368";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ inet_green {
+ label = "WAP-5813n:green:inet";
+ gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ power_green {
+ label = "WAP-5813n:green:power";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ wps_green {
+ label = "WAP-5813n:green:wps";
+ gpios = <&gpio0 23 GPIO_ACTIVE_LOW>;
+ };
+
+ power_red {
+ label = "WAP-5813n:red:power";
+ gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ inet_red {
+ label = "WAP-5813n:red:inet";
+ gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&gpio0 {
+ status = "okay";
+};
+
+&pflash {
+ status = "okay";
+};
+
+&uart0 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/arch/mips/mach-bmips/Kconfig b/arch/mips/mach-bmips/Kconfig
index 4438c62bae..936b67f5f2 100644
--- a/arch/mips/mach-bmips/Kconfig
+++ b/arch/mips/mach-bmips/Kconfig
@@ -132,6 +132,17 @@ config BOARD_COMTREND_VR3032U
ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs,
and a BCM6362 (integrated).
+config BOARD_COMTREND_WAP5813N
+ bool "Comtrend WAP-5813n board"
+ depends on SOC_BMIPS_BCM6368
+ select BMIPS_SUPPORTS_BOOT_RAM
+ help
+ Comtrend WAP-5813n boards have a BCM6369 SoC with 64 MB of RAM and
+ 8 MB of flash (CFI).
+ Between its different peripherals there's a BCM53115 switch with 5
+ ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs,
+ and a BCM4322 (miniPCI).
+
config BOARD_HUAWEI_HG556A
bool "Huawei EchoLife HG556a"
depends on SOC_BMIPS_BCM6358
@@ -197,6 +208,7 @@ config BMIPS_SUPPORTS_BOOT_RAM
source "board/comtrend/ar5387un/Kconfig"
source "board/comtrend/ct5361/Kconfig"
source "board/comtrend/vr3032u/Kconfig"
+source "board/comtrend/wap5813n/Kconfig"
source "board/huawei/hg556a/Kconfig"
source "board/netgear/cg3100d/Kconfig"
source "board/sagem/f@st1704/Kconfig"
diff --git a/board/comtrend/wap5813n/Kconfig b/board/comtrend/wap5813n/Kconfig
new file mode 100644
index 00..2f2a14faae
--- /dev/null
+++ b/board/comtrend/wap5813n/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_COMTREND_WAP5813N
+
+config SYS_BOARD
+ default "wap5813n"
+
+config SYS_VENDOR
+ default "comtrend"
+
+config SYS_CONFIG_NAME
+ default "comtrend_wap58
[U-Boot] [PATCH v2 2/3] MIPS: add support for Broadcom MIPS BCM6368 SoC family
Signed-off-by: Álvaro Fernández Rojas
---
v2: Remove board Kconfig
arch/mips/dts/brcm,bcm6368.dtsi | 168 ++
arch/mips/mach-bmips/Kconfig | 12 +++
include/configs/bmips_bcm6368.h | 30 ++
include/dt-bindings/clock/bcm6368-clock.h | 31 ++
include/dt-bindings/reset/bcm6368-reset.h | 22
5 files changed, 263 insertions(+)
create mode 100644 arch/mips/dts/brcm,bcm6368.dtsi
create mode 100644 include/configs/bmips_bcm6368.h
create mode 100644 include/dt-bindings/clock/bcm6368-clock.h
create mode 100644 include/dt-bindings/reset/bcm6368-reset.h
diff --git a/arch/mips/dts/brcm,bcm6368.dtsi b/arch/mips/dts/brcm,bcm6368.dtsi
new file mode 100644
index 00..1bb538a1f3
--- /dev/null
+++ b/arch/mips/dts/brcm,bcm6368.dtsi
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2017 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "brcm,bcm6368";
+
+ aliases {
+ spi0 = &spi;
+ };
+
+ cpus {
+ reg = <0x1000 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
+
+ cpu@0 {
+ compatible = "brcm,bcm6368-cpu", "mips,mips4Kc";
+ device_type = "cpu";
+ reg = <0>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu@1 {
+ compatible = "brcm,bcm6368-cpu", "mips,mips4Kc";
+ device_type = "cpu";
+ reg = <1>;
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ periph_osc: periph-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ u-boot,dm-pre-reloc;
+ };
+
+ periph_clk: periph-clk {
+ compatible = "brcm,bcm6345-clk";
+ reg = <0x1004 0x4>;
+ #clock-cells = <1>;
+ };
+ };
+
+ pflash: nor@1800 {
+ compatible = "cfi-flash";
+ reg = <0x1800 0x200>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ status = "disabled";
+ };
+
+ ubus {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ pll_cntl: syscon@1008 {
+ compatible = "syscon";
+ reg = <0x1008 0x4>;
+ };
+
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ regmap = <&pll_cntl>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
+
+ periph_rst: reset-controller@1010 {
+ compatible = "brcm,bcm6345-reset";
+ reg = <0x1010 0x4>;
+ #reset-cells = <1>;
+ };
+
+ wdt: watchdog@105c {
+ compatible = "brcm,bcm6345-wdt";
+ reg = <0x105c 0xc>;
+ clocks = <&periph_osc>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdt>;
+ };
+
+ gpio1: gpio-controller@1080 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1080 0x4>, <0x1088 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <6>;
+
+ status = "disabled";
+ };
+
+ gpio0: gpio-controller@1084 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1084 0x4>, <0x108c 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ status = "disabled";
+ };
+
+ leds: led-controller@10d0 {
+ compatible = "brcm,bcm6358-leds";
+ reg = <0x10d0 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
+ uart0: serial@1100 {
+ compatible = "brcm,bcm6345-uart";
+ reg = <0x1100 0x18>;
+
[U-Boot] [PATCH v2 1/3] dm: cpu: bmips: add BCM6368 support
Signed-off-by: Álvaro Fernández Rojas
---
v2: no changes
drivers/cpu/bmips_cpu.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/cpu/bmips_cpu.c b/drivers/cpu/bmips_cpu.c
index 1eb744adcd..2e3f1de74e 100644
--- a/drivers/cpu/bmips_cpu.c
+++ b/drivers/cpu/bmips_cpu.c
@@ -46,6 +46,17 @@ DECLARE_GLOBAL_DATA_PTR;
#define DMIPSPLLCFG_6358_N2_SHIFT 29
#define DMIPSPLLCFG_6358_N2_MASK (0x7 << DMIPSPLLCFG_6358_N2_SHIFT)
+#define REG_BCM6368_DDR_DMIPSPLLCFG0x12a0
+#define DMIPSPLLCFG_6368_P1_SHIFT 0
+#define DMIPSPLLCFG_6368_P1_MASK (0xf << DMIPSPLLCFG_6368_P1_SHIFT)
+#define DMIPSPLLCFG_6368_P2_SHIFT 4
+#define DMIPSPLLCFG_6368_P2_MASK (0xf << DMIPSPLLCFG_6368_P2_SHIFT)
+#define DMIPSPLLCFG_6368_NDIV_SHIFT16
+#define DMIPSPLLCFG_6368_NDIV_MASK (0x1ff << DMIPSPLLCFG_6368_NDIV_SHIFT)
+#define REG_BCM6368_DDR_DMIPSPLLDIV0x12a4
+#define DMIPSPLLDIV_6368_MDIV_SHIFT0
+#define DMIPSPLLDIV_6368_MDIV_MASK (0xff << DMIPSPLLDIV_6368_MDIV_SHIFT)
+
#define REG_BCM63268_MISC_STRAPBUS 0x1814
#define STRAPBUS_63268_FCVO_SHIFT 21
#define STRAPBUS_63268_FCVO_MASK (0xf << STRAPBUS_63268_FCVO_SHIFT)
@@ -157,6 +168,22 @@ static ulong bcm6358_get_cpu_freq(struct bmips_cpu_priv
*priv)
return (16 * 100 * n1 * n2) / m1;
}
+static ulong bcm6368_get_cpu_freq(struct bmips_cpu_priv *priv)
+{
+ unsigned int tmp, p1, p2, ndiv, m1;
+
+ tmp = readl_be(priv->regs + REG_BCM6368_DDR_DMIPSPLLCFG);
+ p1 = (tmp & DMIPSPLLCFG_6368_P1_MASK) >> DMIPSPLLCFG_6368_P1_SHIFT;
+ p2 = (tmp & DMIPSPLLCFG_6368_P2_MASK) >> DMIPSPLLCFG_6368_P2_SHIFT;
+ ndiv = (tmp & DMIPSPLLCFG_6368_NDIV_MASK) >>
+ DMIPSPLLCFG_6368_NDIV_SHIFT;
+
+ tmp = readl_be(priv->regs + REG_BCM6368_DDR_DMIPSPLLDIV);
+ m1 = (tmp & DMIPSPLLDIV_6368_MDIV_MASK) >> DMIPSPLLDIV_6368_MDIV_SHIFT;
+
+ return (((64 * 100) / p1) * p2 * ndiv) / m1;
+}
+
static ulong bcm63268_get_cpu_freq(struct bmips_cpu_priv *priv)
{
unsigned int mips_pll_fcvo;
@@ -230,6 +257,12 @@ static const struct bmips_cpu_hw bmips_cpu_bcm6358 = {
.get_cpu_count = bcm6358_get_cpu_count,
};
+static const struct bmips_cpu_hw bmips_cpu_bcm6368 = {
+ .get_cpu_desc = bmips_short_cpu_desc,
+ .get_cpu_freq = bcm6368_get_cpu_freq,
+ .get_cpu_count = bcm6358_get_cpu_count,
+};
+
static const struct bmips_cpu_hw bmips_cpu_bcm63268 = {
.get_cpu_desc = bmips_long_cpu_desc,
.get_cpu_freq = bcm63268_get_cpu_freq,
@@ -327,6 +360,9 @@ static const struct udevice_id bmips_cpu_ids[] = {
.compatible = "brcm,bcm6358-cpu",
.data = (ulong)&bmips_cpu_bcm6358,
}, {
+ .compatible = "brcm,bcm6368-cpu",
+ .data = (ulong)&bmips_cpu_bcm6368,
+ }, {
.compatible = "brcm,bcm63268-cpu",
.data = (ulong)&bmips_cpu_bcm63268,
},
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] mips: bmips: add BCM6368 SoC support
BCM6368 is a dual core BCM63xx SoC. v2: Remove board Kconfig on patch 2 and clean defconfig Álvaro Fernández Rojas (3): dm: cpu: bmips: add BCM6368 support MIPS: add support for Broadcom MIPS BCM6368 SoC family MIPS: add BMIPS Comtrend WAP-5813n board arch/mips/dts/Makefile| 1 + arch/mips/dts/brcm,bcm6368.dtsi | 168 ++ arch/mips/dts/comtrend,wap-5813n.dts | 65 arch/mips/mach-bmips/Kconfig | 24 + board/comtrend/wap5813n/Kconfig | 12 +++ board/comtrend/wap5813n/MAINTAINERS | 6 ++ board/comtrend/wap5813n/Makefile | 5 + board/comtrend/wap5813n/wap-5813n.c | 7 ++ configs/comtrend_wap5813n_ram_defconfig | 43 drivers/cpu/bmips_cpu.c | 36 +++ include/configs/bmips_bcm6368.h | 30 ++ include/configs/comtrend_wap5813n.h | 19 include/dt-bindings/clock/bcm6368-clock.h | 31 ++ include/dt-bindings/reset/bcm6368-reset.h | 22 14 files changed, 469 insertions(+) create mode 100644 arch/mips/dts/brcm,bcm6368.dtsi create mode 100644 arch/mips/dts/comtrend,wap-5813n.dts create mode 100644 board/comtrend/wap5813n/Kconfig create mode 100644 board/comtrend/wap5813n/MAINTAINERS create mode 100644 board/comtrend/wap5813n/Makefile create mode 100644 board/comtrend/wap5813n/wap-5813n.c create mode 100644 configs/comtrend_wap5813n_ram_defconfig create mode 100644 include/configs/bmips_bcm6368.h create mode 100644 include/configs/comtrend_wap5813n.h create mode 100644 include/dt-bindings/clock/bcm6368-clock.h create mode 100644 include/dt-bindings/reset/bcm6368-reset.h -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: use different BOARD_INIT MACRO for spl and tpl
> On 20 Jan 2018, at 11:00, Kever Yang wrote: > > SPL and TPL may not always need spl_board_init() at the same time. > > Signed-off-by: Kever Yang Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: use built-in device tree in bootefi command
The bootefi command has two parameters: the address of the executable and
the address of the flattened device tree.
When executing the devicetree command in grub this command can only
replace an existing device tree. So we always want to pass a device tree.
With the patch the device tree defaults to the internal one. But of cause
the user still can supply his one via the second parameter.
One use case is booting via iPXE from an iSCSI drive. As we may be able
to choose between different operating systems in the iPXE menu we cannot
know the correct device tree when invoking bootefi. The dtb might not even
be installed on a local device.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 51213c0293..c7f2887df2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -276,7 +276,7 @@ exit:
return ret;
}
-static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
+static int do_bootefi_bootmgr_exec(struct fdt_header *fdt_addr)
{
struct efi_device_path *device_path, *file_path;
void *addr;
@@ -310,10 +310,34 @@ static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
/* Interpreter command to boot an arbitrary EFI image from memory */
static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
- char *saddr, *sfdt;
- unsigned long addr, fdt_addr = 0;
+ char *saddr;
+ unsigned long addr;
+ struct fdt_header *fdt_addr = NULL;
efi_status_t r;
+ /* Set the device tree address */
+ if (argc > 2) {
+ fdt_addr = (struct fdt_header *)simple_strtoul(
+ argv[2], NULL, 16);
+ } else {
+ /* If no device tree is supplied, try using the internal one */
+ fdt_addr = (struct fdt_header *)gd->fdt_blob;
+ if (fdt_addr)
+ printf("Using built-in device tree\n");
+ }
+
+ /* Validate the device tree */
+ if (fdt_addr) {
+ int err = fdt_check_header(fdt_addr);
+
+ if (err < 0) {
+ printf("The device tree is not valid\n");
+ debug("libfdt fdt_check_header(): %s\n",
+ fdt_strerror(err));
+ return CMD_RET_FAILURE;
+ }
+ }
+
if (argc < 2)
return CMD_RET_USAGE;
#ifdef CONFIG_CMD_BOOTEFI_HELLO
@@ -362,21 +386,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
} else
#endif
if (!strcmp(argv[1], "bootmgr")) {
- unsigned long fdt_addr = 0;
-
- if (argc > 2)
- fdt_addr = simple_strtoul(argv[2], NULL, 16);
-
return do_bootefi_bootmgr_exec(fdt_addr);
} else {
saddr = argv[1];
addr = simple_strtoul(saddr, NULL, 16);
-
- if (argc > 2) {
- sfdt = argv[2];
- fdt_addr = simple_strtoul(sfdt, NULL, 16);
- }
}
printf("## Starting EFI application at %08lx ...\n", addr);
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On Sat, 20 Jan 2018 12:29:22 + Russell King wrote: > On Sat, Jan 20, 2018 at 11:31:19AM +, Marc Zyngier wrote: > > Define enough. These patches allow these CPUs to cope with variant-2, > > and only variant-2. Variant-1 is still work in progress across all > > architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM > > implementations, and only A15 is susceptible to variant-3a. > > I think you need to be really careful about statements like this. > > As you know, it is possible to run a 32bit environment in a VM on > the 64bit CPUs. So, its entirely possible to run a 32bit setup > on a Cortex A72 for example, and that means such a setup _is_ > vulnerable to variant 3a. Absolutely. Which is why I was careful to say A8/A9/A12/A15/A17 in all the comments I made regarding these patches. Running 32bit code on an A72, virtualized or not, is still running on an A72. If you run such a configuration, you then need to apply the same mitigations as on the arm64 side. In a virtualized environment, KVM/arm64 will provide paravirtualized services that can be called to ensure BP invalidation. Running bare metal will require CPU-specific methods. > Do people do this? That isn't something we can really know, but > I think as long as its allowed, you can bet that someone will, > and someone will end up using it in a production environment. > > So, it can't be ignored. I'm certainly not stating that we should ignore it. But I'm trying to plug the systems that I know people are using before tackling the ones they may be using. Thanks, M. -- Without deviation from the norm, progress is not possible. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] mrvl_uart.sh and Turris Omnia (was: [EXT] Re: [PATCH v4 0/6] Support for the Turris Omnia router)
Hi Kosta, Am 20.01.2018 um 10:48 schrieb Kostya Porotchkin: > Which Marvell SoC is used on this platform? According to Linux DT filename it's an Armada 385. > The script I added recently covert only the new Armada SoCs like A8K and > A8K+. > It will not work with A3K family. # UART recovery downloader for Armada SoCs echo -e "\nMarvell recovery image downloader for Armada SoC family." echo -e "- The speed-up option is not awailable in SoC families prior to A8K+" echo -e "- This utility is not compatible with Armada 37xx SoC family\n" https://patchwork.ozlabs.org/patch/843021/ It doesn't rule out anything other than 37xx, sounding very generic and making no specific statements about earlier 32-bit models. ;) If it's known to be 7K/8K only, then you should spell that out please. Note that I've just sent out some potentially conflicting output cleanups that I noticed above. Another comment: The kwboot tool is particularly handy in that -p allows to send a binary u-boot-spl.kwb (such as from our Open Build Service) with default of "BOOT_FROM spi" for turris_omnia here, without needing to rebuild from sources with "BOOT_FROM uart" like I seem to need to for mrvl_uart.sh. Are you planning to re-implement that for your script? Regards, Andreas > Original message > From: Andreas Färber > Date: 1/20/18 05:34 (GMT+02:00) > To: Stefan Roese , u-boot@lists.denx.de, Kostya Porotchkin > > Cc: Marek Behún , Tomas Hlavacek > > Subject: [EXT] Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia > router > > External Email > > -- > Am 20.01.2018 um 02:40 schrieb Andreas Färber: >> Hi, >> >> Am 18.01.2018 um 18:20 schrieb Stefan Roese: >>> On 17.01.2018 16:52, Andreas Färber wrote: Am 09.06.2017 um 19:28 schrieb Marek Behún: > This is the fourth version of patches for adding support for the > Turris Omnia board, a router developed by the CZ.NIC. I'm still facing trouble testing turris_omnia on latest v2018.01. First, that made me notice there's no README for how to test and deploy. I'm aware of temporary: sendbeacon /dev/ttyUSBx >>> >>> I have to admit, that don't know anything about this "sendbeacon" >>> tool. > > https://gitlab.labs.nic.cz/turris/misc/tree/master/sendbeacon > ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p >>> >>> This is what I have used, when I tested / debugged images for >>> Armada XP / 38x. Please note that the init sequence is somewhat >>> "fragile" - so I added the -q and -s parameters, to optionally >>> finetune the startup timings: >>> >>> # kwboot >>> ... >>> -q : use specific request-delay >>> -s : use specific response-timeout >>> >>> You might what to play a bit with these parameters as well. >> >> I saw them but had no idea what to pass as values. ;) >> I did try -a, but it worked with and without. >> >>> BTW: I don't have access to the Omnia router, so I can't >>> test anything on this specific platform. >>> >>> BTW2: Kosta from Marvell just recently added a new tool / script, >>> to help debug / boot Marvell MVEBU boards: >>> >>> tools/mrvl_uart.sh >>> >>> He told me that its better to use than the "old" kwboot tool. >>> I never found the time to use it up until now, so I have no >>> personal experience. But I'm pretty sure that Kosta did a >>> great job here. So please give it a try. >> >> I did not get it to work ... or was not patient enough. > > It seems, just as with kwboot, the tool alone is not enough. If I use > sendbeacon before and in mrvl_uart.sh just press enter without another > reset, then the transfer does work for me, and if in the script I add -b > $default_baudrate to the minicom line, then I also see useful output. > > But it does not affect the reported non-SPL boot breakage, i.e. it still > reboots from SPI immediately after loading from UART. > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools/mrvl_uart.sh: Tidy script output
Fix a typo in help output (awailable -> available).
Tidy the grammar - not the board connects to a port, we do.
While at it, be consistent in upper-casing the comments.
Fixes: eee4835d22 ("tools: Add Marvell recovery image download script")
Cc: Konstantin Porotchkin
Cc: Stefan Roese
Cc: Igal Liberman
Signed-off-by: Andreas Färber
---
tools/mrvl_uart.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/mrvl_uart.sh b/tools/mrvl_uart.sh
index 500fa117eb..6824208902 100755
--- a/tools/mrvl_uart.sh
+++ b/tools/mrvl_uart.sh
@@ -46,13 +46,13 @@ then
echo -e "\nMarvell recovery image downloader for Armada SoC family."
echo -e "Command syntax:"
echo -e "\t$(basename $0) [2|4|8]"
-echo -e "\tport - serial port the target board connected to"
+echo -e "\tport - serial port the target board is connected to"
echo -e "\tfile - recovery boot image for target download"
echo -e "\t2|4|8 - times to increase the default serial port speed by"
echo -e "For example - load the image over ttyUSB0 @ 460800 baud:"
echo -e "$(basename $0) /dev/ttyUSB0 /tmp/flash-image.bin 4\n"
echo -e "=WARNING="
-echo -e "- The speed-up option is not awailable in SoC families prior to
A8K+"
+echo -e "- The speed-up option is not available in SoC families prior to
A8K+"
echo -e "- This utility is not compatible with Armada 37xx SoC family\n"
fi
@@ -111,7 +111,7 @@ stty -F $port raw ignbrk time 5 $fast_baudrate
sx -vv $file > $port < $port
#sx-at91 $port $file
-# return the port to the default speed
+# Return the port to the default speed
stty -F $port raw ignbrk time 5 $default_baudrate
# Optional - fire up Minicom
--
2.13.6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
Hi On Sat, Jan 20, 2018 at 12:31 PM, Marc Zyngier wrote: > On Sat, 20 Jan 2018 11:45:08 +0100 > Michael Nazzareno Trimarchi wrote: > >> Hi Marc >> >> On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier wrote: >> > On Fri, 19 Jan 2018 16:56:14 -0500 >> > Tom Rini wrote: >> > >> >> Hey all, >> >> >> >> So, now that things have quieted down a little bit in this area, I've >> >> been wondering about something. Over on the U-Boot side of things, are >> >> there changes we need to make in order to support the kernel side of the >> >> various mitigations properly? I know that for example currently >> >> https://developer.arm.com/support/security-update talks about ATF >> >> patches, in the context of AArch64 however. But on the other hand for >> >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but >> >> there is for non-Linux OSes. >> >> >> >> And, in the event I'm also missing something else entirely that we need >> >> to do here, is there something that we need to be doing? Or is it still >> >> too early at this point in time to know? >> > >> > I've so far posted two revisions of a small patch series that deals >> > with variant-2 on the affected 32bit Cortex-A cores. These patches are >> > currently stashed on the branch[1] pointed at by the web page you >> > mentioned. >> > >> > A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from >> > secure mode. Cortex-A12/A17 do not need this. >> >> So IBE is not a pre-requisite for Cortex A9 family. Is this correct? > > Indeed. I'm not even sure A9 has that bit at all (ACTLR is > implementation specific). BPIALL works on A9 without any other setting. > >> I have already back--ported those patches on kernel 3.4. Is those enough? > > Define enough. These patches allow these CPUs to cope with variant-2, > and only variant-2. Variant-1 is still work in progress across all > architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM > implementations, and only A15 is susceptible to variant-3a. > Just talking on variant-2 . If I understand for the variant 1 people are working on compiler side. Problem is that sometime It's not possible to re-compile userspace for the pre-build userspace library provide by the vendor. Michael > Thanks, > > M. > -- > Without deviation from the norm, progress is not possible. -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools/mrvl_uart.sh: Fix minicom baudrate
minicom doesn't inherit the baudrate from stty but uses its own
defaults, such as for example 57600, whereas we expect 115200 here.
Explicitly tell minicom which baudrate to use.
Fixes: eee4835d22 ("tools: Add Marvell recovery image download script")
Cc: Konstantin Porotchkin
Cc: Stefan Roese
Cc: Igal Liberman
Signed-off-by: Andreas Färber
---
tools/mrvl_uart.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mrvl_uart.sh b/tools/mrvl_uart.sh
index 6b04d7ae2c..500fa117eb 100755
--- a/tools/mrvl_uart.sh
+++ b/tools/mrvl_uart.sh
@@ -115,5 +115,5 @@ sx -vv $file > $port < $port
stty -F $port raw ignbrk time 5 $default_baudrate
# Optional - fire up Minicom
-minicom -D $port
+minicom -D $port -b $default_baudrate
--
2.13.6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On Sat, 20 Jan 2018 11:45:08 +0100 Michael Nazzareno Trimarchi wrote: > Hi Marc > > On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier wrote: > > On Fri, 19 Jan 2018 16:56:14 -0500 > > Tom Rini wrote: > > > >> Hey all, > >> > >> So, now that things have quieted down a little bit in this area, I've > >> been wondering about something. Over on the U-Boot side of things, are > >> there changes we need to make in order to support the kernel side of the > >> various mitigations properly? I know that for example currently > >> https://developer.arm.com/support/security-update talks about ATF > >> patches, in the context of AArch64 however. But on the other hand for > >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but > >> there is for non-Linux OSes. > >> > >> And, in the event I'm also missing something else entirely that we need > >> to do here, is there something that we need to be doing? Or is it still > >> too early at this point in time to know? > > > > I've so far posted two revisions of a small patch series that deals > > with variant-2 on the affected 32bit Cortex-A cores. These patches are > > currently stashed on the branch[1] pointed at by the web page you > > mentioned. > > > > A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from > > secure mode. Cortex-A12/A17 do not need this. > > So IBE is not a pre-requisite for Cortex A9 family. Is this correct? Indeed. I'm not even sure A9 has that bit at all (ACTLR is implementation specific). BPIALL works on A9 without any other setting. > I have already back--ported those patches on kernel 3.4. Is those enough? Define enough. These patches allow these CPUs to cope with variant-2, and only variant-2. Variant-1 is still work in progress across all architectures, variant-3 (aka Meltdown) doesn't concern 32bit ARM implementations, and only A15 is susceptible to variant-3a. Thanks, M. -- Without deviation from the norm, progress is not possible. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] MIPS: add BMIPS Comtrend WAP-5813n board
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/dts/comtrend,wap-5813n.dts| 65 +
board/comtrend/wap5813n/Kconfig | 12 ++
board/comtrend/wap5813n/MAINTAINERS | 6 +++
board/comtrend/wap5813n/Makefile| 5 +++
board/comtrend/wap5813n/wap-5813n.c | 7
configs/comtrend_wap5813n_ram_defconfig | 45 +++
include/configs/comtrend_wap5813n.h | 19 ++
7 files changed, 159 insertions(+)
create mode 100644 arch/mips/dts/comtrend,wap-5813n.dts
create mode 100644 board/comtrend/wap5813n/Kconfig
create mode 100644 board/comtrend/wap5813n/MAINTAINERS
create mode 100644 board/comtrend/wap5813n/Makefile
create mode 100644 board/comtrend/wap5813n/wap-5813n.c
create mode 100644 configs/comtrend_wap5813n_ram_defconfig
create mode 100644 include/configs/comtrend_wap5813n.h
diff --git a/arch/mips/dts/comtrend,wap-5813n.dts
b/arch/mips/dts/comtrend,wap-5813n.dts
new file mode 100644
index 00..29386e2662
--- /dev/null
+++ b/arch/mips/dts/comtrend,wap-5813n.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2017 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "brcm,bcm6368.dtsi"
+
+/ {
+ model = "Comtrend WAP-5813n";
+ compatible = "comtrend,wap-5813n", "brcm,bcm6368";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ inet_green {
+ label = "WAP-5813n:green:inet";
+ gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ power_green {
+ label = "WAP-5813n:green:power";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ wps_green {
+ label = "WAP-5813n:green:wps";
+ gpios = <&gpio0 23 GPIO_ACTIVE_LOW>;
+ };
+
+ power_red {
+ label = "WAP-5813n:red:power";
+ gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ inet_red {
+ label = "WAP-5813n:red:inet";
+ gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&gpio0 {
+ status = "okay";
+};
+
+&pflash {
+ status = "okay";
+};
+
+&uart0 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/board/comtrend/wap5813n/Kconfig b/board/comtrend/wap5813n/Kconfig
new file mode 100644
index 00..2f2a14faae
--- /dev/null
+++ b/board/comtrend/wap5813n/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_COMTREND_WAP5813N
+
+config SYS_BOARD
+ default "wap5813n"
+
+config SYS_VENDOR
+ default "comtrend"
+
+config SYS_CONFIG_NAME
+ default "comtrend_wap5813n"
+
+endif
diff --git a/board/comtrend/wap5813n/MAINTAINERS
b/board/comtrend/wap5813n/MAINTAINERS
new file mode 100644
index 00..f4d99796b4
--- /dev/null
+++ b/board/comtrend/wap5813n/MAINTAINERS
@@ -0,0 +1,6 @@
+COMTREND WAP-5813N BOARD
+M: Álvaro Fernández Rojas
+S: Maintained
+F: board/comtrend/wap-5813n/
+F: include/configs/comtrend_wap-5813n.h
+F: configs/comtrend_wap5813n_ram_defconfig
diff --git a/board/comtrend/wap5813n/Makefile b/board/comtrend/wap5813n/Makefile
new file mode 100644
index 00..fd7799305d
--- /dev/null
+++ b/board/comtrend/wap5813n/Makefile
@@ -0,0 +1,5 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += wap-5813n.o
diff --git a/board/comtrend/wap5813n/wap-5813n.c
b/board/comtrend/wap5813n/wap-5813n.c
new file mode 100644
index 00..d181ca68a0
--- /dev/null
+++ b/board/comtrend/wap5813n/wap-5813n.c
@@ -0,0 +1,7 @@
+/*
+ * Copyright (C) 2017 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
diff --git a/configs/comtrend_wap5813n_ram_defconfig
b/configs/comtrend_wap5813n_ram_defconfig
new file mode 100644
index 00..5d5c584370
--- /dev/null
+++ b/configs/comtrend_wap5813n_ram_defconfig
@@ -0,0 +1,45 @@
+CONFIG_MIPS=y
+CONFIG_SYS_TEXT_BASE=0x8001
+CONFIG_ARCH_BMIPS=y
+CONFIG_SOC_BMIPS_BCM6368=y
+# CONFIG_MIPS_BOOT_CMDLINE_LEGACY is not set
+# CONFIG_MIPS_BOOT_ENV_LEGACY is not set
+CONFIG_MIPS_BOOT_FDT=y
+CONFIG_DEFAULT_DEVICE_TREE="comtrend,wap-5813n"
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x400
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="WAP-5813n # "
+CONFIG_CMD_CPU=y
+CONFIG_CMD_LICENSE=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXIST
[U-Boot] [PATCH 2/3] MIPS: add support for Broadcom MIPS BCM6368 SoC family
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/dts/brcm,bcm6368.dtsi | 168 ++
arch/mips/mach-bmips/Kconfig | 24 +
include/configs/bmips_bcm6368.h | 30 ++
include/dt-bindings/clock/bcm6368-clock.h | 31 ++
include/dt-bindings/reset/bcm6368-reset.h | 22
5 files changed, 275 insertions(+)
create mode 100644 arch/mips/dts/brcm,bcm6368.dtsi
create mode 100644 include/configs/bmips_bcm6368.h
create mode 100644 include/dt-bindings/clock/bcm6368-clock.h
create mode 100644 include/dt-bindings/reset/bcm6368-reset.h
diff --git a/arch/mips/dts/brcm,bcm6368.dtsi b/arch/mips/dts/brcm,bcm6368.dtsi
new file mode 100644
index 00..1bb538a1f3
--- /dev/null
+++ b/arch/mips/dts/brcm,bcm6368.dtsi
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2017 Álvaro Fernández Rojas
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "brcm,bcm6368";
+
+ aliases {
+ spi0 = &spi;
+ };
+
+ cpus {
+ reg = <0x1000 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
+
+ cpu@0 {
+ compatible = "brcm,bcm6368-cpu", "mips,mips4Kc";
+ device_type = "cpu";
+ reg = <0>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu@1 {
+ compatible = "brcm,bcm6368-cpu", "mips,mips4Kc";
+ device_type = "cpu";
+ reg = <1>;
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ periph_osc: periph-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ u-boot,dm-pre-reloc;
+ };
+
+ periph_clk: periph-clk {
+ compatible = "brcm,bcm6345-clk";
+ reg = <0x1004 0x4>;
+ #clock-cells = <1>;
+ };
+ };
+
+ pflash: nor@1800 {
+ compatible = "cfi-flash";
+ reg = <0x1800 0x200>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ status = "disabled";
+ };
+
+ ubus {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ pll_cntl: syscon@1008 {
+ compatible = "syscon";
+ reg = <0x1008 0x4>;
+ };
+
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ regmap = <&pll_cntl>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
+
+ periph_rst: reset-controller@1010 {
+ compatible = "brcm,bcm6345-reset";
+ reg = <0x1010 0x4>;
+ #reset-cells = <1>;
+ };
+
+ wdt: watchdog@105c {
+ compatible = "brcm,bcm6345-wdt";
+ reg = <0x105c 0xc>;
+ clocks = <&periph_osc>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdt>;
+ };
+
+ gpio1: gpio-controller@1080 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1080 0x4>, <0x1088 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <6>;
+
+ status = "disabled";
+ };
+
+ gpio0: gpio-controller@1084 {
+ compatible = "brcm,bcm6345-gpio";
+ reg = <0x1084 0x4>, <0x108c 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ status = "disabled";
+ };
+
+ leds: led-controller@10d0 {
+ compatible = "brcm,bcm6358-leds";
+ reg = <0x10d0 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
+ uart0: serial@1100 {
+ compatible = "brcm,bcm6345-uart";
+ reg = <0x1100 0x18>;
+ clocks = <&per
[U-Boot] [PATCH 1/3] dm: cpu: bmips: add BCM6368 support
Signed-off-by: Álvaro Fernández Rojas
---
drivers/cpu/bmips_cpu.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/cpu/bmips_cpu.c b/drivers/cpu/bmips_cpu.c
index 1eb744adcd..2e3f1de74e 100644
--- a/drivers/cpu/bmips_cpu.c
+++ b/drivers/cpu/bmips_cpu.c
@@ -46,6 +46,17 @@ DECLARE_GLOBAL_DATA_PTR;
#define DMIPSPLLCFG_6358_N2_SHIFT 29
#define DMIPSPLLCFG_6358_N2_MASK (0x7 << DMIPSPLLCFG_6358_N2_SHIFT)
+#define REG_BCM6368_DDR_DMIPSPLLCFG0x12a0
+#define DMIPSPLLCFG_6368_P1_SHIFT 0
+#define DMIPSPLLCFG_6368_P1_MASK (0xf << DMIPSPLLCFG_6368_P1_SHIFT)
+#define DMIPSPLLCFG_6368_P2_SHIFT 4
+#define DMIPSPLLCFG_6368_P2_MASK (0xf << DMIPSPLLCFG_6368_P2_SHIFT)
+#define DMIPSPLLCFG_6368_NDIV_SHIFT16
+#define DMIPSPLLCFG_6368_NDIV_MASK (0x1ff << DMIPSPLLCFG_6368_NDIV_SHIFT)
+#define REG_BCM6368_DDR_DMIPSPLLDIV0x12a4
+#define DMIPSPLLDIV_6368_MDIV_SHIFT0
+#define DMIPSPLLDIV_6368_MDIV_MASK (0xff << DMIPSPLLDIV_6368_MDIV_SHIFT)
+
#define REG_BCM63268_MISC_STRAPBUS 0x1814
#define STRAPBUS_63268_FCVO_SHIFT 21
#define STRAPBUS_63268_FCVO_MASK (0xf << STRAPBUS_63268_FCVO_SHIFT)
@@ -157,6 +168,22 @@ static ulong bcm6358_get_cpu_freq(struct bmips_cpu_priv
*priv)
return (16 * 100 * n1 * n2) / m1;
}
+static ulong bcm6368_get_cpu_freq(struct bmips_cpu_priv *priv)
+{
+ unsigned int tmp, p1, p2, ndiv, m1;
+
+ tmp = readl_be(priv->regs + REG_BCM6368_DDR_DMIPSPLLCFG);
+ p1 = (tmp & DMIPSPLLCFG_6368_P1_MASK) >> DMIPSPLLCFG_6368_P1_SHIFT;
+ p2 = (tmp & DMIPSPLLCFG_6368_P2_MASK) >> DMIPSPLLCFG_6368_P2_SHIFT;
+ ndiv = (tmp & DMIPSPLLCFG_6368_NDIV_MASK) >>
+ DMIPSPLLCFG_6368_NDIV_SHIFT;
+
+ tmp = readl_be(priv->regs + REG_BCM6368_DDR_DMIPSPLLDIV);
+ m1 = (tmp & DMIPSPLLDIV_6368_MDIV_MASK) >> DMIPSPLLDIV_6368_MDIV_SHIFT;
+
+ return (((64 * 100) / p1) * p2 * ndiv) / m1;
+}
+
static ulong bcm63268_get_cpu_freq(struct bmips_cpu_priv *priv)
{
unsigned int mips_pll_fcvo;
@@ -230,6 +257,12 @@ static const struct bmips_cpu_hw bmips_cpu_bcm6358 = {
.get_cpu_count = bcm6358_get_cpu_count,
};
+static const struct bmips_cpu_hw bmips_cpu_bcm6368 = {
+ .get_cpu_desc = bmips_short_cpu_desc,
+ .get_cpu_freq = bcm6368_get_cpu_freq,
+ .get_cpu_count = bcm6358_get_cpu_count,
+};
+
static const struct bmips_cpu_hw bmips_cpu_bcm63268 = {
.get_cpu_desc = bmips_long_cpu_desc,
.get_cpu_freq = bcm63268_get_cpu_freq,
@@ -327,6 +360,9 @@ static const struct udevice_id bmips_cpu_ids[] = {
.compatible = "brcm,bcm6358-cpu",
.data = (ulong)&bmips_cpu_bcm6358,
}, {
+ .compatible = "brcm,bcm6368-cpu",
+ .data = (ulong)&bmips_cpu_bcm6368,
+ }, {
.compatible = "brcm,bcm63268-cpu",
.data = (ulong)&bmips_cpu_bcm63268,
},
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] mips: bmips: add BCM6368 SoC support
BCM6368 is a dual core BCM63xx SoC. Álvaro Fernández Rojas (3): dm: cpu: bmips: add BCM6368 support MIPS: add support for Broadcom MIPS BCM6368 SoC family MIPS: add BMIPS Comtrend WAP-5813n board arch/mips/dts/brcm,bcm6368.dtsi | 168 ++ arch/mips/dts/comtrend,wap-5813n.dts | 65 arch/mips/mach-bmips/Kconfig | 24 + board/comtrend/wap5813n/Kconfig | 12 +++ board/comtrend/wap5813n/MAINTAINERS | 6 ++ board/comtrend/wap5813n/Makefile | 5 + board/comtrend/wap5813n/wap-5813n.c | 7 ++ configs/comtrend_wap5813n_ram_defconfig | 45 drivers/cpu/bmips_cpu.c | 36 +++ include/configs/bmips_bcm6368.h | 30 ++ include/configs/comtrend_wap5813n.h | 19 include/dt-bindings/clock/bcm6368-clock.h | 31 ++ include/dt-bindings/reset/bcm6368-reset.h | 22 13 files changed, 470 insertions(+) create mode 100644 arch/mips/dts/brcm,bcm6368.dtsi create mode 100644 arch/mips/dts/comtrend,wap-5813n.dts create mode 100644 board/comtrend/wap5813n/Kconfig create mode 100644 board/comtrend/wap5813n/MAINTAINERS create mode 100644 board/comtrend/wap5813n/Makefile create mode 100644 board/comtrend/wap5813n/wap-5813n.c create mode 100644 configs/comtrend_wap5813n_ram_defconfig create mode 100644 include/configs/bmips_bcm6368.h create mode 100644 include/configs/comtrend_wap5813n.h create mode 100644 include/dt-bindings/clock/bcm6368-clock.h create mode 100644 include/dt-bindings/reset/bcm6368-reset.h -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On Fri, 19 Jan 2018 23:21:44 +0100 Mark Kettenis wrote: > > Date: Fri, 19 Jan 2018 16:56:14 -0500 > > From: Tom Rini > > > > Hey all, > > > > So, now that things have quieted down a little bit in this area, I've > > been wondering about something. Over on the U-Boot side of things, are > > there changes we need to make in order to support the kernel side of the > > various mitigations properly? I know that for example currently > > https://developer.arm.com/support/security-update talks about ATF > > patches, in the context of AArch64 however. But on the other hand for > > variant 2, there's nothing listed on the Linux side for 32bit ARM, but > > there is for non-Linux OSes. > > > > And, in the event I'm also missing something else entirely that we need > > to do here, is there something that we need to be doing? Or is it still > > too early at this point in time to know? > > I think that for AArch32, the following bit advice is relevant: > > For Cortex-A15, set ACTLR[0]==1 from early initialization of the > processor, and invalidate the branch predictor by performing an > ICIALLU instruction. > > For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this > register may be read-only in non-secure mode. And unless I missed > something Linux makes the same assumption. Indeed. This bit is only writeable from the secure side, and we assume that Linux runs on the non-secure side. > If U-Boot provides the PSCI implementation it should probably flush > the BTB on affected 32-bit processors and should defenitely flush on > 64-bit processors. If U-Boot implements the secure firmware, then it should invalidate the BTB on entry to Monitor mode (AArch32) or EL3 (AArch64), before taking any branch. That's only for the affected CPUs, of course, and you probably don't want to do it for unaffected parts. Thanks, M. -- Without deviation from the norm, progress is not possible. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mips: bmips: increment SYS_MALLOC_F_LEN
This prevents the following ENOMEM: Error binding driver 'bmips_cpu': -12 Signed-off-by: Álvaro Fernández Rojas --- arch/mips/mach-bmips/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/mach-bmips/Kconfig b/arch/mips/mach-bmips/Kconfig index e3e1da3c28..db8b40523a 100644 --- a/arch/mips/mach-bmips/Kconfig +++ b/arch/mips/mach-bmips/Kconfig @@ -1,6 +1,9 @@ menu "Broadcom MIPS platforms" depends on ARCH_BMIPS +config SYS_MALLOC_F_LEN + default 0x1000 + config SYS_SOC default "bcm3380" if SOC_BMIPS_BCM3380 default "bcm6328" if SOC_BMIPS_BCM6328 -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On Fri, 19 Jan 2018 17:10:04 -0600 Nishanth Menon wrote: > On 01/19/2018 04:21 PM, Mark Kettenis wrote: > >> Date: Fri, 19 Jan 2018 16:56:14 -0500 > >> From: Tom Rini > >> > >> Hey all, > >> > >> So, now that things have quieted down a little bit in this area, I've > >> been wondering about something. Over on the U-Boot side of things, are > >> there changes we need to make in order to support the kernel side of the > >> various mitigations properly? I know that for example currently > >> https://developer.arm.com/support/security-update talks about ATF > >> patches, in the context of AArch64 however. But on the other hand for > >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but > >> there is for non-Linux OSes. > >> > >> And, in the event I'm also missing something else entirely that we need > >> to do here, is there something that we need to be doing? Or is it still > >> too early at this point in time to know? > > > > I think that for AArch32, the following bit advice is relevant: > > > >For Cortex-A15, set ACTLR[0]==1 from early initialization of the > >processor, and invalidate the branch predictor by performing an > >ICIALLU instruction. > > > > For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this > > register may be read-only in non-secure mode. And unless I missed > > something Linux makes the same assumption. > > > > If U-Boot provides the PSCI implementation it should probably flush > > the BTB on affected 32-bit processors and should defenitely flush on > > 64-bit processors. > > Seeing the traffic in kernel, I think I understand these two I know of > at least? > > A8/9/12/17: > "So without IBE set, as the comments above say, the flush won't do > anything." > https://marc.info/?l=linux-arm-kernel&m=151566145121435&w=2 This applies to A8 only. A9/A12/A17 do not need any additional settings for BPIALL to work correctly. > A15: ACTLR > https://marc.info/?l=linux-arm-kernel&m=151562519425981&w=2 > > Am I misunderstanding the list we need to do in u-boot? > A15 requires IBE to be set for ICIALLU to invalidate the branch predictor. Thanks, M. -- Without deviation from the norm, progress is not possible. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
Hi Marc On Sat, Jan 20, 2018 at 11:42 AM, Marc Zyngier wrote: > On Fri, 19 Jan 2018 16:56:14 -0500 > Tom Rini wrote: > >> Hey all, >> >> So, now that things have quieted down a little bit in this area, I've >> been wondering about something. Over on the U-Boot side of things, are >> there changes we need to make in order to support the kernel side of the >> various mitigations properly? I know that for example currently >> https://developer.arm.com/support/security-update talks about ATF >> patches, in the context of AArch64 however. But on the other hand for >> variant 2, there's nothing listed on the Linux side for 32bit ARM, but >> there is for non-Linux OSes. >> >> And, in the event I'm also missing something else entirely that we need >> to do here, is there something that we need to be doing? Or is it still >> too early at this point in time to know? > > I've so far posted two revisions of a small patch series that deals > with variant-2 on the affected 32bit Cortex-A cores. These patches are > currently stashed on the branch[1] pointed at by the web page you > mentioned. > > A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from > secure mode. Cortex-A12/A17 do not need this. So IBE is not a pre-requisite for Cortex A9 family. Is this correct? I have already back--ported those patches on kernel 3.4. Is those enough? Michael > > Thanks, > > M. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti > -- > Without deviation from the norm, progress is not possible. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On Fri, 19 Jan 2018 16:56:14 -0500 Tom Rini wrote: > Hey all, > > So, now that things have quieted down a little bit in this area, I've > been wondering about something. Over on the U-Boot side of things, are > there changes we need to make in order to support the kernel side of the > various mitigations properly? I know that for example currently > https://developer.arm.com/support/security-update talks about ATF > patches, in the context of AArch64 however. But on the other hand for > variant 2, there's nothing listed on the Linux side for 32bit ARM, but > there is for non-Linux OSes. > > And, in the event I'm also missing something else entirely that we need > to do here, is there something that we need to be doing? Or is it still > too early at this point in time to know? I've so far posted two revisions of a small patch series that deals with variant-2 on the affected 32bit Cortex-A cores. These patches are currently stashed on the branch[1] pointed at by the web page you mentioned. A prerequisite for Cortex-A8 and A15 is that ACTLR[0] (IBE) is set from secure mode. Cortex-A12/A17 do not need this. Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti -- Without deviation from the norm, progress is not possible. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: use different BOARD_INIT MACRO for spl and tpl
SPL and TPL may not always need spl_board_init() at the same time. Signed-off-by: Kever Yang --- common/spl/Kconfig | 7 +++ common/spl/spl.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 7aae826..3e6f526 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -754,6 +754,13 @@ config TPL if TPL +config TPL_BOARD_INIT + bool "Call board-specific initialization in TPL" + help + If this option is enabled, U-Boot will call the function + spl_board_init() from board_init_r(). This function should be + provided by the board. + config TPL_LDSCRIPT string "Linker script for the TPL stage" depends on TPL diff --git a/common/spl/spl.c b/common/spl/spl.c index ac2c6ca..ec6ac69 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -395,7 +395,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) timer_init(); #endif -#ifdef CONFIG_SPL_BOARD_INIT +#if CONFIG_IS_ENABLED(BOARD_INIT) spl_board_init(); #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v4 0/6] Support for the Turris Omnia router
Hello, Which Marvell SoC is used on this platform? The script I added recently covert only the new Armada SoCs like A8K and A8K+. It will not work with A3K family. Regards Kosta Sent from my Samsung Galaxy smartphone. Original message From: Andreas Färber Date: 1/20/18 05:34 (GMT+02:00) To: Stefan Roese , u-boot@lists.denx.de, Kostya Porotchkin Cc: Marek Behún , Tomas Hlavacek Subject: [EXT] Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router External Email -- Am 20.01.2018 um 02:40 schrieb Andreas Färber: > Hi, > > Am 18.01.2018 um 18:20 schrieb Stefan Roese: >> On 17.01.2018 16:52, Andreas Färber wrote: >>> Am 09.06.2017 um 19:28 schrieb Marek Behún: This is the fourth version of patches for adding support for the Turris Omnia board, a router developed by the CZ.NIC. >>> >>> I'm still facing trouble testing turris_omnia on latest v2018.01. >>> >>> First, that made me notice there's no README for how to test and deploy. >>> I'm aware of temporary: >>> sendbeacon /dev/ttyUSBx >> >> I have to admit, that don't know anything about this "sendbeacon" >> tool. https://gitlab.labs.nic.cz/turris/misc/tree/master/sendbeacon >>> ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p >> >> This is what I have used, when I tested / debugged images for >> Armada XP / 38x. Please note that the init sequence is somewhat >> "fragile" - so I added the -q and -s parameters, to optionally >> finetune the startup timings: >> >> # kwboot >> ... >> -q : use specific request-delay >> -s : use specific response-timeout >> >> You might what to play a bit with these parameters as well. > > I saw them but had no idea what to pass as values. ;) > I did try -a, but it worked with and without. > >> BTW: I don't have access to the Omnia router, so I can't >> test anything on this specific platform. >> >> BTW2: Kosta from Marvell just recently added a new tool / script, >> to help debug / boot Marvell MVEBU boards: >> >> tools/mrvl_uart.sh >> >> He told me that its better to use than the "old" kwboot tool. >> I never found the time to use it up until now, so I have no >> personal experience. But I'm pretty sure that Kosta did a >> great job here. So please give it a try. > > I did not get it to work ... or was not patient enough. It seems, just as with kwboot, the tool alone is not enough. If I use sendbeacon before and in mrvl_uart.sh just press enter without another reset, then the transfer does work for me, and if in the script I add -b $default_baudrate to the minicom line, then I also see useful output. But it does not affect the reported non-SPL boot breakage, i.e. it still reboots from SPI immediately after loading from UART. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
Hi Nishanth On Sat, Jan 20, 2018 at 12:10 AM, Nishanth Menon wrote: > On 01/19/2018 04:21 PM, Mark Kettenis wrote: >>> >>> Date: Fri, 19 Jan 2018 16:56:14 -0500 >>> From: Tom Rini >>> >>> Hey all, >>> >>> So, now that things have quieted down a little bit in this area, I've >>> been wondering about something. Over on the U-Boot side of things, are >>> there changes we need to make in order to support the kernel side of the >>> various mitigations properly? I know that for example currently >>> https://developer.arm.com/support/security-update talks about ATF >>> patches, in the context of AArch64 however. But on the other hand for >>> variant 2, there's nothing listed on the Linux side for 32bit ARM, but >>> there is for non-Linux OSes. >>> >>> And, in the event I'm also missing something else entirely that we need >>> to do here, is there something that we need to be doing? Or is it still >>> too early at this point in time to know? >> >> >> I think that for AArch32, the following bit advice is relevant: >> >>For Cortex-A15, set ACTLR[0]==1 from early initialization of the >>processor, and invalidate the branch predictor by performing an >>ICIALLU instruction. >> >> For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this >> register may be read-only in non-secure mode. And unless I missed >> something Linux makes the same assumption. >> >> If U-Boot provides the PSCI implementation it should probably flush >> the BTB on affected 32-bit processors and should defenitely flush on >> 64-bit processors. > > > Seeing the traffic in kernel, I think I understand these two I know of at > least? > > A8/9/12/17: > "So without IBE set, as the comments above say, the flush won't do > anything." Regarding IBE set, is this can be set later on boot stage after MLO? Michael > https://marc.info/?l=linux-arm-kernel&m=151566145121435&w=2 > > A15: ACTLR > https://marc.info/?l=linux-arm-kernel&m=151562519425981&w=2 > > Am I misunderstanding the list we need to do in u-boot? > > -- > Regards, > Nishanth Menon > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router
Hi Andreas, On 20.01.2018 03:30, Andreas Färber wrote: Am 20.01.2018 um 02:40 schrieb Andreas Färber: Hi, Am 18.01.2018 um 18:20 schrieb Stefan Roese: On 17.01.2018 16:52, Andreas Färber wrote: Am 09.06.2017 um 19:28 schrieb Marek Behún: This is the fourth version of patches for adding support for the Turris Omnia board, a router developed by the CZ.NIC. I'm still facing trouble testing turris_omnia on latest v2018.01. First, that made me notice there's no README for how to test and deploy. I'm aware of temporary: sendbeacon /dev/ttyUSBx I have to admit, that don't know anything about this "sendbeacon" tool. ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p This is what I have used, when I tested / debugged images for Armada XP / 38x. Please note that the init sequence is somewhat "fragile" - so I added the -q and -s parameters, to optionally finetune the startup timings: # kwboot ... -q : use specific request-delay -s : use specific response-timeout You might what to play a bit with these parameters as well. I saw them but had no idea what to pass as values. ;) I did try -a, but it worked with and without. BTW: I don't have access to the Omnia router, so I can't test anything on this specific platform. BTW2: Kosta from Marvell just recently added a new tool / script, to help debug / boot Marvell MVEBU boards: tools/mrvl_uart.sh He told me that its better to use than the "old" kwboot tool. I never found the time to use it up until now, so I have no personal experience. But I'm pretty sure that Kosta did a great job here. So please give it a try. I did not get it to work ... or was not patient enough. # or without -p when s/BOOT_FROM spi/BOOT_FROM uart/ and permanent: tftpboot 0x100 u-boot-spl.kwb sf probe sf update 0x100 0 $filesize I used to have the original factory CZ.NIC U-Boot in SPI and booted test versions only via sendbeacon+kwboot. With mainline that appears to be broken - the CONFIG_ARMADA_38X code in arch/arm/mach-mvebu/spl.c seems to run into !boot_device and instead of UART tries to boot from SPI - nothing happens then and kwboot complains. I can force it to continue booting from UART by commenting out the if. So Stefan, it looks like your auto-detection is not working here and the Kconfig option to force it was dropped prematurely. Hmmm. Then some patch must have broken this UART boot-ability. Could you by any chance git-bisect, to check which patch broke this functionality? Perhaps some of the newer patches from Sean Nyekjaer? I've so far found that v2017.11 had UART boot working okay. git-bisect pointed to this commit: e83e2b390038c9075642cb243a6292241beb8d73 is the first bad commit commit e83e2b390038c9075642cb243a6292241beb8d73 Author: Sean Nyekjaer Date: Fri Nov 24 14:01:28 2017 +0100 arm: mvebu: fix boot from UART when in fallback mode It's the first 8 bits of the bootrom error register that contain the boot error/fallback error code. Let's check that and continue to boot from UART. Signed-off-by: Sean Nyekjaer Signed-off-by: Stefan Roese :04 04 c4c5cb4287ae8c3ced749a9734213a5844ddf1d9 772ec1e6401cbb2616b1337ff8757b72240458b3 M arch Many thanks for digging into this. I'll try to check UART booting with a A38x board sometime next week. Perhaps Sean already has some ideas in the meantime... Thanks, Stefan Regards, Andreas When forcing UART, as soon as the progress surpasses 99%, it reboots into SPI SPL without any error message. Using the old U-Boot fork I've tried flashing u-boot-spl.kwb - similarly it gets stuck in the SPL trying to boot on from SPI. After a while it reboots, and so on in a loop. So it seems that non-SPL U-Boot 2018.01 is broken, on my 2 GB model. Hmmm. I can only I have reconfirmed (with our GCC 7.2.1) that no version works for me: v2017.07 did not have turris_omnia defconfig yet b6ee860b87d8accedfb7a1fd5414f7c483603234 bad (adds turris_omnia) v2017.09 bad v2017.11 bad v2018.01 bad master bad (c4cb6e64bf068eaa1f7c96cb37da7ae6d40bbbff / arc merge) So I have nothing to bisect and wonder how Marek tested this... I also ran into a couple DDR3 training failures when booting via UART. No such training problems observed booting from SPI. Using the same U-Boot version, meaning same DDR init code? Yes. Only difference being BOOT_FROM and the spl.c modification. Thats strange. I have not really worked with Armada 38x for quite some time, but I don't remember any such problems that you describe here. I might need to dig up an Armada 38x board and give it a try myself... Regards, Andreas Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinf
[U-Boot] Please pull u-boot-marvell/master
Hi Tom, please pull the following patches for the Marvell A38x DDR code from Chris. Thanks, Stefan The following changes since commit 086ebcd40e9bf8efc520f1b177fd8e3cc0e506fa: Merge git://git.denx.de/u-boot-fsl-qoriq (2018-01-17 13:48:35 -0500) are available in the Git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to 672e5598301b63f95d7dcceb4436f3cb40643f88: ddr: marvell: update ddr controller init and freq (2018-01-19 16:30:29 +0100) Chris Packham (4): ddr: marvell: only assert M_ODT[0] on write for a single CS ddr: marvell: use correct TREFI value ddr: marvell: update additional ODT setting ddr: marvell: update ddr controller init and freq drivers/ddr/marvell/a38x/ddr3_init.h | 3 +- drivers/ddr/marvell/a38x/ddr3_topology_def.h | 3 +- drivers/ddr/marvell/a38x/ddr3_training.c | 50 +++- drivers/ddr/marvell/a38x/ddr3_training_db.c | 19 + drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c | 22 +++ drivers/ddr/marvell/a38x/ddr3_training_static.c | 3 +- 6 files changed, 62 insertions(+), 38 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] ddr: marvell: update DDR driver
Hi Chris, On 18.01.2018 05:16, Chris Packham wrote: I have a custom board that sees correctable ECC errors (when running memtester[1] from Linux). When I used Marvell's bootloader I didn't see the errors. I've also had a tame hardware engineer (if there is such a thing) looking at the timing waveforms comparing the stock u-boot behaviour against Marvell's bootloader. The changes for this series have been derived by comparing scope captures and register output between the same system running stock u-boot and Marvell's USP. Changes in v2: - Update tODT_OFF_WR as well - Added patches 2-4 Chris Packham (4): ddr: marvell: only assert M_ODT[0] on write for a single CS ddr: marvell: use correct TREFI value ddr: marvell: update additional ODT setting ddr: marvell: update ddr controller init and freq drivers/ddr/marvell/a38x/ddr3_init.h | 3 +- drivers/ddr/marvell/a38x/ddr3_topology_def.h | 3 +- drivers/ddr/marvell/a38x/ddr3_training.c | 50 +++- drivers/ddr/marvell/a38x/ddr3_training_db.c | 19 + drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c | 22 +++ drivers/ddr/marvell/a38x/ddr3_training_static.c | 3 +- 6 files changed, 62 insertions(+), 38 deletions(-) Big thanks for working on this. All patches: Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
