[U-Boot] [PATCH 2/2] board: allwinner: sun50i-h6: Add Orangepi Lite2 support
OrangePi Lite2 is Allwinner H6 based open-source SBC,
which support:
- Allwinner H6 Quad-core 64-bit ARM Cortex-A53
- GPU Mali-T720
- 1GB LPDDR3 RAM
- AXP805 PMIC
- AP6356S Wifi/BT
- USB 2.0, USB 3.0 Host, OTG
- HDMI port
- 5V/2A DC power supply
Signed-off-by: Jagan Teki
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/sun50i-h6-orangepi-lite2.dts | 11 +++
board/sunxi/MAINTAINERS | 5 +
configs/orangepi_lite2_defconfig | 12
4 files changed, 29 insertions(+)
create mode 100644 arch/arm/dts/sun50i-h6-orangepi-lite2.dts
create mode 100644 configs/orangepi_lite2_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3093c1185e..f7d35da7b3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -396,6 +396,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
dtb-$(CONFIG_MACH_SUN50I_H6) += \
+ sun50i-h6-orangepi-lite2.dtb \
sun50i-h6-orangepi-one-plus.dtb \
sun50i-h6-pine-h64.dtb
dtb-$(CONFIG_MACH_SUN50I) += \
diff --git a/arch/arm/dts/sun50i-h6-orangepi-lite2.dts
b/arch/arm/dts/sun50i-h6-orangepi-lite2.dts
new file mode 100644
index 00..e098a2475f
--- /dev/null
+++ b/arch/arm/dts/sun50i-h6-orangepi-lite2.dts
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2018 Jagan Teki
+ */
+
+#include "sun50i-h6-orangepi.dtsi"
+
+/ {
+ model = "OrangePi Lite2";
+ compatible = "xunlong,orangepi-lite2", "allwinner,sun50i-h6";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index d34cf7db30..478e37285f 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -335,6 +335,11 @@ S: Maintained
F: configs/A20-Olimex-SOM204-EVB_defconfig
F: configs/A20-Olimex-SOM204-EVB-eMMC_defconfig
+ORANGEPI LITE2 BOARD
+M: Jagan Teki
+S: Maintained
+F: configs/orangepi_lite2_defconfig
+
ORANGEPI ONE PLUS BOARD
M: Jagan Teki
S: Maintained
diff --git a/configs/orangepi_lite2_defconfig b/configs/orangepi_lite2_defconfig
new file mode 100644
index 00..e5f7d15bf6
--- /dev/null
+++ b/configs/orangepi_lite2_defconfig
@@ -0,0 +1,12 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I_H6=y
+CONFIG_MMC0_CD_PIN="PF6"
+# CONFIG_PSCI_RESET is not set
+CONFIG_NR_DRAM_BANKS=1
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-orangepi-lite2"
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm64: allwinner: h6: Add common orangepi nodes into dtsi
Based on the information from hardware schematics and orangepi
vendor orangepi H6 boards, One Plus and Lite2 shares common nodes
like axp805, uart, mmc0 etc. The common differences between them is
- One Plus, has Ethernet
- Lite2, has Wifi, USB3, CSI port.
So, add common orangepi nodes into sun50i-h6-orangepi.dtsi so-that
it case use on respective orangepi h6 board dts files.
Cc: zhaoyifan
Signed-off-by: Jagan Teki
---
arch/arm/dts/sun50i-h6-orangepi-one-plus.dts | 140 +
arch/arm/dts/sun50i-h6-orangepi.dtsi | 150 +++
2 files changed, 151 insertions(+), 139 deletions(-)
create mode 100644 arch/arm/dts/sun50i-h6-orangepi.dtsi
diff --git a/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
b/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
index 0612c19cd9..12e17567ab 100644
--- a/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
+++ b/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
@@ -4,147 +4,9 @@
* Author: Jagan Teki
*/
-/dts-v1/;
-
-#include "sun50i-h6.dtsi"
-
-#include
+#include "sun50i-h6-orangepi.dtsi"
/ {
model = "OrangePi One Plus";
compatible = "xunlong,orangepi-one-plus", "allwinner,sun50i-h6";
-
- aliases {
- serial0 =
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- vmmc-supply = <_cldo1>;
- cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
- bus-width = <4>;
- status = "okay";
-};
-
-_i2c {
- status = "okay";
-
- axp805: pmic@36 {
- compatible = "x-powers,axp805", "x-powers,axp806";
- reg = <0x36>;
- interrupt-parent = <_intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <1>;
- x-powers,self-working-mode;
-
- regulators {
- reg_aldo1: aldo1 {
- regulator-always-on;
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-name = "vcc-pl";
- };
-
- reg_aldo2: aldo2 {
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-name = "vcc-ac200";
- };
-
- reg_aldo3: aldo3 {
- regulator-always-on;
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-name = "vcc25-dram";
- };
-
- reg_bldo1: bldo1 {
- regulator-always-on;
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-name = "vcc-bias-pll";
- };
-
- reg_bldo2: bldo2 {
- regulator-always-on;
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-name = "vcc-efuse-pcie-hdmi-io";
- };
-
- reg_bldo3: bldo3 {
- regulator-always-on;
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-name = "vcc-dcxoio";
- };
-
- bldo4 {
- /* unused */
- };
-
- reg_cldo1: cldo1 {
- regulator-always-on;
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-name = "vcc-3v3";
- };
-
- reg_cldo2: cldo2 {
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-name = "vcc-wifi-1";
- };
-
- reg_cldo3: cldo3 {
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-name = "vcc-wifi-2";
- };
-
- reg_dcdca: dcdca {
- regulator-always-on;
- regulator-min-microvolt = <81>;
-
Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support
On 03/11/18 4:58 PM, Akash Gajjar wrote: Rockpro64 is rk3399 based board from pine64.org. add initial board support for Rockpro64. complete board support will be added later in upcoming patchsets. Signed-off-by: Akash Gajjar --- arch/arm/dts/Makefile |1 + arch/arm/dts/rk3399-rockpro64.dts | 519 +++ Does it pure Linux sync file? if yes mention the commit id details on commit message. arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi | 1535 Send this separately, more convenient to review ddr changes separately. arch/arm/mach-rockchip/rk3399/Kconfig | 10 + board/rockchip/rockpro64/Kconfig | 15 + board/rockchip/rockpro64/MAINTAINERS |6 + board/rockchip/rockpro64/Makefile |7 + board/rockchip/rockpro64/rockpro64.c | 94 ++ configs/rockpro64-rk3399_defconfig | 78 + include/configs/rockpro64.h| 15 + 10 files changed, 2280 insertions(+) create mode 100644 arch/arm/dts/rk3399-rockpro64.dts create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi create mode 100644 board/rockchip/rockpro64/Kconfig create mode 100644 board/rockchip/rockpro64/MAINTAINERS create mode 100644 board/rockchip/rockpro64/Makefile create mode 100644 board/rockchip/rockpro64/rockpro64.c create mode 100644 configs/rockpro64-rk3399_defconfig create mode 100644 include/configs/rockpro64.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index d36447d18d..8a84cf55a3 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -51,6 +51,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3399-puma-ddr1333.dtb \ rk3399-puma-ddr1600.dtb \ rk3399-puma-ddr1866.dtb \ + rk3399-rockpro64.dtb \ rv1108-evb.dtb dtb-$(CONFIG_ARCH_MESON) += \ meson-gxbb-nanopi-k2.dtb \ diff --git a/arch/arm/dts/rk3399-rockpro64.dts b/arch/arm/dts/rk3399-rockpro64.dts new file mode 100644 index 00..8497a1124b --- /dev/null +++ b/arch/arm/dts/rk3399-rockpro64.dts @@ -0,0 +1,519 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2018 Akash Gajjar + */ + +/dts-v1/; +#include +#include +#include "rk3399.dtsi" +#include "rk3399-sdram-lpddr4-1600.dtsi" if this change related to u-boot, just sync Linux dts file and create -u-boot.dtsi and include this on that. Just to understand, what has been tested with this support? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] sunxi: A64/H3/H5 DT updates
On Mon, Nov 5, 2018 at 11:20 AM Vasily Khoruzhick wrote: > > On Sun, Nov 4, 2018 at 9:13 PM Jagan Teki wrote: > > > > On Mon, Oct 29, 2018 at 6:27 AM Andre Przywara > > wrote: > > > > > > This updates the .dts and .dtsi files used in U-Boot to what will become > > > the new DTs in Linux 4.20 (anytime soon). > > > Those updates are not too useful for U-Boot itself, but keep the DTs > > > consistent and allow to directly pass U-Boot's copy to any kernel, by > > > using > > > $fdtcontroladdr. > > > There is a small change in the A64 .dtsi, which breaks compatibility with > > > older kernels (stable releases and those found on distro installer > > > images), > > > so the second patch fixes this by re-adding the missing compatible > > > string to the system controller node. > > > The updates include the H5 and also H3, as they are very close and need to > > > be updated together. > > > > > > I ran into issues with the H6, so will post an update for that later. > > > > > > I see that this somewhat overlaps with Vasily's Pinebook series, I am > > > happy to arrange something here. Originally I wanted to wait for the files > > > to hit Linus' tree (to get stable commit IDs), but I sending this now > > > to not block Vasily. > > > > So, does this sync is on top of pinebook dts sync patch[1]? if ie case > > then we can squash 1/4 with [1] so all sync changes in one commit. > > Just merge Andre's patches, I'll rebase mine on top of his and resend. Marked as "Waiting for Upstream" in patchwork, will push it MW, just send your series on top it. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] misc: fs_loader: Fix compiler warning
Fix compiler warning
drivers/misc/fs_loader.c:193:9: warning: format ‘%d’ expects
argument of type ‘int’, but argument 5 has type ‘size_t
{aka long unsigned int}’ [-Wformat=]
Signed-off-by: Keerthy
---
drivers/misc/fs_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index 5afc941..baa5f83 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -190,7 +190,7 @@ static int fw_get_filesystem_firmware(struct
device_platdata *plat,
fw_priv->offset, firmware->size, );
if (ret) {
- debug("Error: %d Failed to read %s from flash %lld != %d.\n",
+ debug("Error: %d Failed to read %s from flash %lld != %zu.\n",
ret, fw_priv->name, actread, firmware->size);
} else {
ret = actread;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] fs: Makefile: Add fs.c under SPL as well as it is needed for fs_loader
Add fs.c under SPL as well as it is needed for fs_loader Signed-off-by: Keerthy --- fs/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/Makefile b/fs/Makefile index bad0c2c..b4ca1b3 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -8,7 +8,6 @@ ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_FAT_SUPPORT) += fat/ obj-$(CONFIG_SPL_EXT_SUPPORT) += ext4/ else -obj-y += fs.o obj-$(CONFIG_FS_BTRFS) += btrfs/ obj-$(CONFIG_FS_CBFS) += cbfs/ @@ -22,4 +21,5 @@ obj-$(CONFIG_CMD_UBIFS) += ubifs/ obj-$(CONFIG_YAFFS2) += yaffs2/ obj-$(CONFIG_CMD_ZFS) += zfs/ endif +obj-y += fs.o obj-y += fs_internal.o -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] misc: fs_loader: Use device_get_global_by_ofnode to get to node
Instead of two staged ofnode_to_offset followed by
device_get_global_by_of_offset approach, direcly use the
device_get_global_by_ofnode to fetch the device.
Signed-off-by: Keerthy
---
drivers/misc/fs_loader.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index b7bb96a..5afc941 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -55,11 +55,9 @@ static int select_fs_dev(struct device_platdata *plat)
node = ofnode_get_by_phandle(plat->phandlepart.phandle);
- int of_offset = ofnode_to_offset(node);
-
struct udevice *dev;
- ret = device_get_global_by_of_offset(of_offset, );
+ ret = device_get_global_by_ofnode(node, );
if (!ret) {
struct blk_desc *desc = blk_get_by_device(dev);
if (desc) {
@@ -190,6 +188,7 @@ static int fw_get_filesystem_firmware(struct
device_platdata *plat,
ret = fs_read(fw_priv->name, (ulong)map_to_sysmem(firmware->data),
fw_priv->offset, firmware->size, );
+
if (ret) {
debug("Error: %d Failed to read %s from flash %lld != %d.\n",
ret, fw_priv->name, actread, firmware->size);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] core: ofnode: Add ofnode_get_addr_size_index
Add ofnode_get_addr_size_index function to fetch the address
and size of the reg space based on index.
Signed-off-by: Keerthy
---
Changes in v2:
* Added the missing header file declaration of the new function.
drivers/core/ofnode.c | 14 ++
include/dm/ofnode.h | 13 +
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index c80e1cb..b98b0b9 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -251,16 +251,15 @@ int ofnode_read_size(ofnode node, const char *propname)
return -EINVAL;
}
-fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
+fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, u64 *size)
{
int na, ns;
- u64 size;
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
- prop_val = of_get_address(ofnode_to_np(node), index, ,
+ prop_val = of_get_address(ofnode_to_np(node), index, size,
);
if (!prop_val)
return FDT_ADDR_T_NONE;
@@ -278,12 +277,19 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
return fdtdec_get_addr_size_fixed(gd->fdt_blob,
ofnode_to_offset(node), "reg",
- index, na, ns, , true);
+ index, na, ns, size, true);
}
return FDT_ADDR_T_NONE;
}
+fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
+{
+ u64 size;
+
+ return ofnode_get_addr_size_index(node, index, );
+}
+
fdt_addr_t ofnode_get_addr(ofnode node)
{
return ofnode_get_addr_index(node, 0);
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 2fc9fa3..149acaa 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -356,6 +356,19 @@ int ofnode_read_size(ofnode node, const char *propname);
phys_addr_t ofnode_get_addr_index(ofnode node, int index);
/**
+ * ofnode_get_addr_size_index() - get an address/size from a node
+ * based on index
+ *
+ * This reads the register address from a node
+ *
+ * @node: node to read from
+ * @index: Index of address to read (0 for first)
+ * @size: Pointer to size of the address
+ * @return address, or FDT_ADDR_T_NONE if not present or invalid
+ */
+phys_addr_t ofnode_get_addr_size_index(ofnode node, int index, u64 *size);
+
+/**
* ofnode_get_addr() - get an address from a node
*
* This reads the register address from a node
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] core: ofnode: Fix ofnode_get_addr_size_index function
Currently the else part of ofnode_get_addr_size_index function
does not fetch addresses based on the index but rather just
returns the base address. Fix that.
Signed-off-by: Keerthy
---
drivers/core/ofnode.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index b7b7ad3..c80e1cb 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -253,12 +253,12 @@ int ofnode_read_size(ofnode node, const char *propname)
fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
{
+ int na, ns;
+ u64 size;
+
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
- u64 size;
- int na;
- int ns;
prop_val = of_get_address(ofnode_to_np(node), index, ,
);
@@ -274,8 +274,11 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
return of_read_number(prop_val, na);
}
} else {
- return fdt_get_base_address(gd->fdt_blob,
- ofnode_to_offset(node));
+ na = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
+ ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+ return fdtdec_get_addr_size_fixed(gd->fdt_blob,
+ ofnode_to_offset(node), "reg",
+ index, na, ns, , true);
}
return FDT_ADDR_T_NONE;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] core: ofnode: Add ofnode_get_addr_size_index
Add ofnode_get_addr_size_index function to fetch the address
and size of the reg space based on index.
Signed-off-by: Keerthy
---
drivers/core/ofnode.c | 14 ++
include/dm/ofnode.h | 13 +
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index c80e1cb..b98b0b9 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -251,16 +251,15 @@ int ofnode_read_size(ofnode node, const char *propname)
return -EINVAL;
}
-fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
+fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, u64 *size)
{
int na, ns;
- u64 size;
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
- prop_val = of_get_address(ofnode_to_np(node), index, ,
+ prop_val = of_get_address(ofnode_to_np(node), index, size,
);
if (!prop_val)
return FDT_ADDR_T_NONE;
@@ -278,12 +277,19 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
return fdtdec_get_addr_size_fixed(gd->fdt_blob,
ofnode_to_offset(node), "reg",
- index, na, ns, , true);
+ index, na, ns, size, true);
}
return FDT_ADDR_T_NONE;
}
+fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
+{
+ u64 size;
+
+ return ofnode_get_addr_size_index(node, index, );
+}
+
fdt_addr_t ofnode_get_addr(ofnode node)
{
return ofnode_get_addr_index(node, 0);
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 2fc9fa3..149acaa 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -356,6 +356,19 @@ int ofnode_read_size(ofnode node, const char *propname);
phys_addr_t ofnode_get_addr_index(ofnode node, int index);
/**
+ * ofnode_get_addr_size_index() - get an address/size from a node
+ * based on index
+ *
+ * This reads the register address from a node
+ *
+ * @node: node to read from
+ * @index: Index of address to read (0 for first)
+ * @size: Pointer to size of the address
+ * @return address, or FDT_ADDR_T_NONE if not present or invalid
+ */
+phys_addr_t ofnode_get_addr_size_index(ofnode node, int index, u64 *size);
+
+/**
* ofnode_get_addr() - get an address from a node
*
* This reads the register address from a node
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] core: ofnode: Fix ofnode_get_addr_size_index function
Currently the else part of ofnode_get_addr_size_index function
does not fetch addresses based on the index but rather just
returns the base address. Fix that.
Signed-off-by: Keerthy
---
drivers/core/ofnode.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index b7b7ad3..c80e1cb 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -253,12 +253,12 @@ int ofnode_read_size(ofnode node, const char *propname)
fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
{
+ int na, ns;
+ u64 size;
+
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
- u64 size;
- int na;
- int ns;
prop_val = of_get_address(ofnode_to_np(node), index, ,
);
@@ -274,8 +274,11 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
return of_read_number(prop_val, na);
}
} else {
- return fdt_get_base_address(gd->fdt_blob,
- ofnode_to_offset(node));
+ na = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
+ ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+ return fdtdec_get_addr_size_fixed(gd->fdt_blob,
+ ofnode_to_offset(node), "reg",
+ index, na, ns, , true);
}
return FDT_ADDR_T_NONE;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] core: ofnode: Add ofnode_get_addr_size_index
On Monday 05 November 2018 11:17 AM, Keerthy wrote:
> Add ofnode_get_addr_size_index function to fetch the address
> and size of the reg space based on index.
I missed the header file hunk. I will send v2 in a bit.
>
> Signed-off-by: Keerthy
> ---
> drivers/core/ofnode.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> index c80e1cb..b98b0b9 100644
> --- a/drivers/core/ofnode.c
> +++ b/drivers/core/ofnode.c
> @@ -251,16 +251,15 @@ int ofnode_read_size(ofnode node, const char *propname)
> return -EINVAL;
> }
>
> -fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
> +fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, u64 *size)
> {
> int na, ns;
> - u64 size;
>
> if (ofnode_is_np(node)) {
> const __be32 *prop_val;
> uint flags;
>
> - prop_val = of_get_address(ofnode_to_np(node), index, ,
> + prop_val = of_get_address(ofnode_to_np(node), index, size,
> );
> if (!prop_val)
> return FDT_ADDR_T_NONE;
> @@ -278,12 +277,19 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
> ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
> return fdtdec_get_addr_size_fixed(gd->fdt_blob,
> ofnode_to_offset(node), "reg",
> - index, na, ns, , true);
> + index, na, ns, size, true);
> }
>
> return FDT_ADDR_T_NONE;
> }
>
> +fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
> +{
> + u64 size;
> +
> + return ofnode_get_addr_size_index(node, index, );
> +}
> +
> fdt_addr_t ofnode_get_addr(ofnode node)
> {
> return ofnode_get_addr_index(node, 0);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] sunxi: A64/H3/H5 DT updates
On Sun, Nov 4, 2018 at 9:13 PM Jagan Teki wrote: > > On Mon, Oct 29, 2018 at 6:27 AM Andre Przywara wrote: > > > > This updates the .dts and .dtsi files used in U-Boot to what will become > > the new DTs in Linux 4.20 (anytime soon). > > Those updates are not too useful for U-Boot itself, but keep the DTs > > consistent and allow to directly pass U-Boot's copy to any kernel, by using > > $fdtcontroladdr. > > There is a small change in the A64 .dtsi, which breaks compatibility with > > older kernels (stable releases and those found on distro installer images), > > so the second patch fixes this by re-adding the missing compatible > > string to the system controller node. > > The updates include the H5 and also H3, as they are very close and need to > > be updated together. > > > > I ran into issues with the H6, so will post an update for that later. > > > > I see that this somewhat overlaps with Vasily's Pinebook series, I am > > happy to arrange something here. Originally I wanted to wait for the files > > to hit Linus' tree (to get stable commit IDs), but I sending this now > > to not block Vasily. > > So, does this sync is on top of pinebook dts sync patch[1]? if ie case > then we can squash 1/4 with [1] so all sync changes in one commit. Just merge Andre's patches, I'll rebase mine on top of his and resend. > [1] https://patchwork.ozlabs.org/patch/990012/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] core: ofnode: Add ofnode_get_addr_size_index
Add ofnode_get_addr_size_index function to fetch the address
and size of the reg space based on index.
Signed-off-by: Keerthy
---
drivers/core/ofnode.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index c80e1cb..b98b0b9 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -251,16 +251,15 @@ int ofnode_read_size(ofnode node, const char *propname)
return -EINVAL;
}
-fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
+fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, u64 *size)
{
int na, ns;
- u64 size;
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
- prop_val = of_get_address(ofnode_to_np(node), index, ,
+ prop_val = of_get_address(ofnode_to_np(node), index, size,
);
if (!prop_val)
return FDT_ADDR_T_NONE;
@@ -278,12 +277,19 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
return fdtdec_get_addr_size_fixed(gd->fdt_blob,
ofnode_to_offset(node), "reg",
- index, na, ns, , true);
+ index, na, ns, size, true);
}
return FDT_ADDR_T_NONE;
}
+fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
+{
+ u64 size;
+
+ return ofnode_get_addr_size_index(node, index, );
+}
+
fdt_addr_t ofnode_get_addr(ofnode node)
{
return ofnode_get_addr_index(node, 0);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] core: ofnode: Fix ofnode_get_addr_size_index function
Currently the else part of ofnode_get_addr_size_index function
does not fetch addresses based on the index but rather just
returns the base address. Fix that.
Signed-off-by: Keerthy
---
drivers/core/ofnode.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index b7b7ad3..c80e1cb 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -253,12 +253,12 @@ int ofnode_read_size(ofnode node, const char *propname)
fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
{
+ int na, ns;
+ u64 size;
+
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
- u64 size;
- int na;
- int ns;
prop_val = of_get_address(ofnode_to_np(node), index, ,
);
@@ -274,8 +274,11 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
return of_read_number(prop_val, na);
}
} else {
- return fdt_get_base_address(gd->fdt_blob,
- ofnode_to_offset(node));
+ na = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
+ ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+ return fdtdec_get_addr_size_fixed(gd->fdt_blob,
+ ofnode_to_offset(node), "reg",
+ index, na, ns, , true);
}
return FDT_ADDR_T_NONE;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] sunxi: A64/H3/H5 DT updates
On Mon, Oct 29, 2018 at 6:27 AM Andre Przywara wrote: > > This updates the .dts and .dtsi files used in U-Boot to what will become > the new DTs in Linux 4.20 (anytime soon). > Those updates are not too useful for U-Boot itself, but keep the DTs > consistent and allow to directly pass U-Boot's copy to any kernel, by using > $fdtcontroladdr. > There is a small change in the A64 .dtsi, which breaks compatibility with > older kernels (stable releases and those found on distro installer images), > so the second patch fixes this by re-adding the missing compatible > string to the system controller node. > The updates include the H5 and also H3, as they are very close and need to > be updated together. > > I ran into issues with the H6, so will post an update for that later. > > I see that this somewhat overlaps with Vasily's Pinebook series, I am > happy to arrange something here. Originally I wanted to wait for the files > to hit Linus' tree (to get stable commit IDs), but I sending this now > to not block Vasily. So, does this sync is on top of pinebook dts sync patch[1]? if ie case then we can squash 1/4 with [1] so all sync changes in one commit. [1] https://patchwork.ozlabs.org/patch/990012/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection
On Mon, Oct 29, 2018 at 2:37 PM Miquel Raynal wrote: > > Hi Jagan, > > Jagan Teki wrote on Tue, 23 Oct 2018 > 16:40:05 +0530: > > > On Thu, Oct 11, 2018 at 3:05 PM Miquel Raynal > > wrote: > > > > > > Today way is to rely on CMD_NAND to be selected and from the root > > > Makefile compile what is in drivers/mtd/nand/raw. > > > > > > While this will work most of the time with decent configurations, it > > > is better to also compile this subsystem upon simple request in the > > > configuration. Otherwise, a user not selecting CMD_NAND but selecting > > > NAND and any of the controller drivers will not see their build. Fix > > > this weird situation by adding a single line in the nand/ directory > > > Kconfig file. > > > > > > Signed-off-by: Miquel Raynal > > > --- > > > drivers/mtd/nand/Makefile | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > > > index a358bc680e..2c33447995 100644 > > > --- a/drivers/mtd/nand/Makefile > > > +++ b/drivers/mtd/nand/Makefile > > > @@ -2,4 +2,5 @@ > > > > > > nandcore-objs := core.o bbt.o > > > obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o > > > +obj-$(CONFIG_NAND) += raw/ > > > > But we even source raw Kconfig path, isn't it? and also how about > > remove this from root Makefile? > > What do you mean by "we even source raw Kconfig path"? It was not > sourced before this modification unless CMD_NAND was selected. > > I agree we should also remove this link between a path being > compiled and a CMD_* symbol in the root Makefile. It will probably > produce a lot of errors though. I'll try when I'll have some time. OK, but If it can't fire any issue as of now, may be we do full cleanup later. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issue with relocating code to DDR
Hello SHEKHAR SINGH, Am 01.11.2018 um 14:44 schrieb SHEKHAR SINGH: Hi All, I am new to U-boot. Currently, I am working on developing U-boot for a new SOC. The SOC has arm926ej-s as the core and is implemented on Xilinx FPGA with SD-card as the boot device. With current setup DDR is already initialized by FPGA and SD card can be accessed using direct addressing. We have added board files and SoC related files to the Uboot directory and is able to successfully compile and get some outputs on UART (debug console). Currently, we have added only support for GPIO and UART drivers. SD Card : 0x - 0x007F SRAM: 0x9000 - 0x90007FFF DDR : 0x4000 - 0x43FF We are facing some issue with the uboot booting. We are able to see the initial uboot prints and debug prints when the stack pointer is in SRAM, but after we relocate the code from SD card to DDR and change the stack pointer to DDR we are getting junk prints on the console. Can anyone help me or suggest me what we are doing wrong here? Thanks in advance for your help. Please see the below UART Log: initcall: 5cdc initcall: 9a84 initcall: 5ccc initcall: 5fbc initcall: 60c0 initcall: 0418 initcall: 6090 initcall: 5fb4 malloc_simple: size=18, ptr=18, limit=400: 9b30 malloc_simple: size=54, ptr=6c, limit=400: 9b48 malloc_simple: size=4, ptr=70, limit=400: 9b9c uclass_find_device_by_seq: 0 -1 uclass_find_device_by_seq: 0 0 - -1 -1 'root_driver' - not found initcall: 6088 initcall: 10b0 initcall: 04a8 initcall: f77c env_init: Environment nowhere init done (ret=0) initcall: 5f88 initcall: f0dc initcall: 000147c0 U-Boot 2018.09 (Nov 01 2018 - 18:33:40 +0530) initcall: 5eac U-Boot code: -> 00024604 BSS: -> 00030608 initcall: 0438 CPU: SoC Version 0.01 CPU clock:75MHz SDRAM clock: 75MHz initcall: 6470 initcall: 5f70 DRAM: initcall: 10ec SDRAM Reg 000 : EDAC Reg 004 : SDRAM Reg 100 : EDAC Reg 104 : EMC Reg : 1ff initcall: 6178 Monitor len: 00030608 Ram size: 0400 gd->relocaddr : 4400 Ram top: 4400 initcall: 5cfc initcall: 6098 initcall: 5d14 initcall: 60a0 initcall: 5e44 Reserving 193k for U-Boot at: 43fcf000 initcall: 5e18 Reserving 1152k for malloc() at: 43eaf000 initcall: 5f1c Reserving 80 Bytes for Board Info at: 43eaefb0 initcall: 60a8 initcall: 5de4 Reserving 200 Bytes for Global Data at: 43eaeee8 initcall: 5d5c initcall: 60b0 initcall: 60c8 initcall: 61f4 gd->relocaddr : 43FCF000 initcall: 5d1c initcall: 60dc RAM Configuration: Bank #0: 4000 64 MiB DRAM: 64 MiB initcall: 5d40 New Stack Pointer is: 43eaeec0 initcall: 5ed8 initcall: 60b8 initcall: 5fd0 __image_copy_start : __image_copy_end : 00024604 gd copied successfully to new gd... Relocation Offset is: 43fcf000 Relocating to Addr 43fcf000, new gd at 43eaeee8, sp at 43eaeec0 Current Stack Pointer 9a60 Cannot say very much... so just some speculations: Stack pointer seems not to be in RAM May your RAM does not work correctly? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/18] serial: 16550: allow the driver to support MediaTek serial
On Sat, 2018-11-03 at 00:09 -0600, Simon Glass wrote:
> Hi Ryder,
>
> On 2 November 2018 at 09:15, Ryder Lee wrote:
> > This patch adds an extra operation in ns16550.c to suuport MediaTek
> > SoCs as we have a highspeed register which influences the calcualtion
> > of the divisor.
> >
> > Note that we don't support the baudrate greater than 115200 currently.
> >
> > Signed-off-by: Ryder Lee
> > Tested-by: Matthias Brugger
> > Reviewed-by: Simon Glass
> > ---
> > drivers/serial/ns16550.c | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Actually it seems to me that we should have a compatible string for
> this and deal with this at run-time?
>
> Is that easy to do here?
>
How about this:
uart0: serial@11002000 {
compatible = "ns16550a";
mediatek,highspeed = <0>;
Ryder
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mt7623 bootup example
On Sun, 2018-11-04 at 11:38 +0100, Frank Wunderlich wrote: > Just to be clear...i tested v2 patches on rc1 > (https://github.com/frank-w/u-boot/tree/bpi-r2_v2) they working well. > > v3 have additional depencies (swig,python-dev same on rc1) and bootargs > seems not to be passed to kernel (rc1=bpi-r2_v3_old and rc3 = bpi-r2_v3) That's because I remove 'gd->bd->bi_boot_params' in v3, but it seems you use legacy method (ATAGs) to pass parameters. I will add it back. > > Gesendet: Samstag, 03. November 2018 um 09:46 Uhr > > Von: "Frank Wunderlich" > > An: s...@chromium.org, "Ryder Lee" > > Cc: u-boot@lists.denx.de > > Betreff: [U-Boot] mt7623 bootup example > > > > Hi Simon, hi Ryder, > > > > i tried Patches so far, they are working well > > > > https://patchwork.ozlabs.org/patch/992398/ > > > > here my github-repo with steps to build: > > > > https://github.com/frank-w/u-boot > > > > there is a build.sh, which compiles uboot the common way with some > > additions like bootmenu and full environment to load a kernel on BPI-R2 > > > > here are instructions how to prepare SD-Card for boot-up: > > > > https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:storage#extended_boot-headers > > > > as you see you need 3 Headers on SD-Card (SDMMC_BOOT, BRLYT, Preloader) and > > the uboot.bin for SD-Card. on emmc imho preloader in boot0-block and uboot > > on main-Partition is enough for uboot to boot > > > > Source: > > https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:uboot#update_uboot > > > > btw. @ryder.lee you have a small typo in the readme: > > Boorom => Bootrom (2 times) Thanks for catching that. > > maybe you can add Infos above from my wiki. Btw. how far is the > > ethernet-driver? then i can replace my 2014-uboot ;) > > OK. Thanks Ryder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Handle RELA absolute relocations properly
On Mon, Nov 5, 2018 at 5:28 AM Alexander Graf wrote: > > With RELA absolute relocations, the relocation target contains our link > offset which we need to remove from the equation again. We did this > properly in the relative relocation path, but not in the absolute one. > > So let's do this for the absolute one as well. That way, u-boot can have > a TEXT_OFFSET of != 0 and still relocate itself properly. > > This fixes a bug where efi_loader did not work on the RISC-V QEMU port. > With this patch, I can successfully run UEFI applications on the RISC-V > QEMU port. > > Reported-by: Auer, Lukas > Signed-off-by: Alexander Graf > --- > lib/efi_loader/efi_runtime.c | 3 +++ > 1 file changed, 3 insertions(+) > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: Ensure memory allocations are page aligned
When the max_addr parameter of efi_find_free_memory() is within bounds
of an existing map and fits the reservation, we just return that address
as allocation value.
That breaks however if max_addr is not page aligned. So ensure that it
always comes to us page aligned, simplifying the allocation logic.
Without this, I've seen breakage where we were allocating pages at -1U
(32bit) which fits into a region that spans beyond 0x1. In that
case, we would return 0x as a valid memory allocation, although
we usually do guarantee they are all page aligned.
Fix this by aligning the max address argument always.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_memory.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 5bd4f4d7fc..1ffcf92eb2 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -294,6 +294,12 @@ static uint64_t efi_find_free_memory(uint64_t len,
uint64_t max_addr)
{
struct list_head *lhandle;
+ /*
+* Prealign input max address, so we simplify our matching
+* logic below and can just reuse it as return pointer.
+*/
+ max_addr &= ~EFI_PAGE_MASK;
+
list_for_each(lhandle, _mem) {
struct efi_mem_list *lmem = list_entry(lhandle,
struct efi_mem_list, link);
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] dm: DM_FLAG_PRE_RELOC flag clean up
Hi Bin,
On 3 November 2018 at 03:48, Bin Meng wrote:
> Hi Simon,
>
> On Sat, Nov 3, 2018 at 2:08 PM Simon Glass wrote:
>>
>> Hi Bin,
>>
>> On 1 November 2018 at 20:25, Bin Meng wrote:
>> > On Sun, Oct 28, 2018 at 9:31 PM Adam Ford wrote:
>> >>
>> >> On Wed, Oct 24, 2018 at 8:32 AM Bin Meng wrote:
>> >> >
>> >> > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
>> >> > bound before relocation. However due to a bug in the DM core,
>> >> > the flag only takes effect when devices are statically declared
>> >> > via U_BOOT_DEVICE(). This bug has been fixed recently by commit
>> >> > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
>> >> > lists_bind_fdt()", but with the fix, it has a side effect that
>> >> > all existing drivers that declared DM_FLAG_PRE_RELOC flag will
>> >> > be bound before relocation now. This may expose potential boot
>> >> > failure on some boards due to insufficient memory during the
>> >> > pre-relocation stage.
>> >> >
>> >> > To mitigate this potential impact, the following changes are
>> >> > implemented:
>> >> >
>> >> > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
>> >> > only supports configuration from device tree (OF_CONTROL)
>> >> > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
>> >> > is statically declared via U_BOOT_DEVICE()
>> >> > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
>> >> > drivers that support both statically declared devices and
>> >> > configuration from device tree
>> >> >
>> >> > This series should be applied on top of u-boot-dm/master, for
>> >> > v2018.11 release.
>> >> >
>> >> >
>> >> > Bin Meng (13):
>> >> > arm: stm32mp: Remove DM_FLAG_PRE_RELOC flag
>> >> > clk: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > gpio: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > i2c: omap24xx: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check
>> >> > mmc: omap: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check
>> >> > pinctrl: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > ram: bmips: Remove DM_FLAG_PRE_RELOC flag
>> >> > timer: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > serial: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > sysreset: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > video: simplefb: Remove DM_FLAG_PRE_RELOC flag
>> >> > watchdog: Remove DM_FLAG_PRE_RELOC flag in various drivers
>> >> > dm: doc: Update description of pre-relocation support
>> >> >
>> >>
>> >> This works just fine for me on the am3517_evm and the omap3_logic boards.
>> >>
>> >> Tested-by Adam Ford
>> >>
>> >
>> > Thanks Adam and Stephen's testing.
>> >
>> > Simon,
>> >
>> > Looks we don't have too much time before release, would you please
>> > test and send the PR?
>> >
>> > Another series
>> > (http://patchwork.ozlabs.org/project/uboot/list/?series=70686)
>> > needs to be pulled in to unblock x86 too.
>>
>> I had assumed we could wait to the next release.
>>
>> Could you please explain what you are wanting me to do here?
>
> Short version:
> As I mentioned in this series' cover letter, "This series should be
> applied on top of u-boot-dm/master, for v2018.11 release.". The other
> x86 series should be applied for this release too.
>
> The long story:
>
> In [1] I said: "It looks that I have to send out a fix to correct
> Tegra in this release now, and leave other clean ups in next
> release.", was because I think the clean up changes are massive and
> only Stephen reported the Tegra was broken by previous series [2]
> which was applied in *u-boot-dm/master* so initially I only wanted to
> send out the Tegra fixes. However later Stefan reported in [3] that
> some x86 boards just don't boot with *u-boot/mater*. Then I had a look
> and suggested adding DM_FLAG_PRE_RELOC flag to x86 CPU drivers, which
> was the x86 fixes series [4] I mentioned above. However the issue is
> that without my fix in series [2], the x86 fix just doesn't work. Then
> I mentioned that in [5] I said "I spent some time to clean up all
> driver usage about DM_FLAG_PRE_RELOC flag" and it should fix Tegra
> (reported) as well as other potential (un-reported) broken.
>
> [1] https://lists.denx.de/pipermail/u-boot/2018-October/345085.html
> [2]
> http://patchwork.ozlabs.org/project/uboot/list/?series=70150=*==both
> [3] https://lists.denx.de/pipermail/u-boot/2018-October/344266.html
> [4] http://patchwork.ozlabs.org/project/uboot/list/?series=70686
> [5] https://lists.denx.de/pipermail/u-boot/2018-October/345479.html
>
> Note both my previous series [2] and x86 fix series [4] are attempting
> to fix the side effect brought up by c0434407b595 ("board_f: Use
> static print_cpuinfo if CONFIG_CPU is active") which was part of the
> MPC83xx CPU uclass driver support. So the root cause is the MPC83xx
> changes. But I am not sure if we can revert that patch easily now, as
> I suspect many later commits are dependent on that one, and we may
>
[U-Boot] [PATCH] efi_loader: Handle RELA absolute relocations properly
With RELA absolute relocations, the relocation target contains our link offset which we need to remove from the equation again. We did this properly in the relative relocation path, but not in the absolute one. So let's do this for the absolute one as well. That way, u-boot can have a TEXT_OFFSET of != 0 and still relocate itself properly. This fixes a bug where efi_loader did not work on the RISC-V QEMU port. With this patch, I can successfully run UEFI applications on the RISC-V QEMU port. Reported-by: Auer, Lukas Signed-off-by: Alexander Graf --- lib/efi_loader/efi_runtime.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index abcf03c5a4..ca66d33e58 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -380,6 +380,9 @@ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map) ulong symidx = rel->info >> SYM_INDEX; extern struct dyn_sym __dyn_sym_start[]; newaddr = __dyn_sym_start[symidx].addr + offset; +#ifdef IS_RELA + newaddr -= CONFIG_SYS_TEXT_BASE; +#endif break; } #endif -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 28/29] riscv: qemu: detect and boot the kernel passed by QEMU
On 04.11.18 13:52, Auer, Lukas wrote:
> On Sat, 2018-11-03 at 20:33 +0100, Alexander Graf wrote:
>>
>> On 03.11.18 18:07, Auer, Lukas wrote:
>>> On Tue, 2018-10-30 at 16:27 +0100, Alexander Graf wrote:
On 30.10.18 16:02, Auer, Lukas wrote:
> On Tue, 2018-10-30 at 13:55 +0100, Lukas Auer wrote:
>> QEMU embeds the location of the kernel image in the device
>> tree.
>> Store
>> this address in the environment as variable kernel_start and
>> use
>> it
>> in
>> CONFIG_BOOTCOMMAND to boot the kernel. Use the device tree
>> passed
>> by
>> the
>> prior boot stage to boot Linux.
>>
>> Signed-off-by: Lukas Auer
>> ---
>>
>> Changes in v2:
>> - Rebase onto u-boot-dm/next
>> - Boot Linux with the device tree provided by the prior boot
>> stage
>>
>> board/emulation/qemu-riscv/Kconfig | 1 +
>> board/emulation/qemu-riscv/qemu-riscv.c | 29
>> +
>> configs/qemu-riscv32_defconfig | 1 +
>> configs/qemu-riscv64_defconfig | 1 +
>> include/configs/qemu-riscv.h| 10 -
>> 5 files changed, 41 insertions(+), 1 deletion(-)
>>
>> diff --git a/board/emulation/qemu-riscv/Kconfig
>> b/board/emulation/qemu-riscv/Kconfig
>> index 37a80db6a9..be5839b7db 100644
>> --- a/board/emulation/qemu-riscv/Kconfig
>> +++ b/board/emulation/qemu-riscv/Kconfig
>> @@ -29,5 +29,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
>> imply CMD_EXT2
>> imply CMD_EXT4
>> imply CMD_FAT
>> +imply BOARD_LATE_INIT
>>
>> endif
>> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
>> b/board/emulation/qemu-riscv/qemu-riscv.c
>> index 2ce093e19a..ee20983095 100644
>> --- a/board/emulation/qemu-riscv/qemu-riscv.c
>> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
>> @@ -19,3 +19,32 @@ int board_init(void)
>>
>> return 0;
>> }
>> +
>> +int board_late_init(void)
>> +{
>> +ulong kernel_start;
>> +ofnode chosen_node;
>> +int ret;
>> +
>> +chosen_node = ofnode_path("/chosen");
>> +if (!ofnode_valid(chosen_node)) {
>> +printf("No chosen node found\n");
>> +return 0;
>> +}
>> +
>> +#ifdef CONFIG_ARCH_RV64I
>> +ret = ofnode_read_u64(chosen_node, "riscv,kernel-
>> start",
>> + (u64 *)_start);
>> +#else
>> +ret = ofnode_read_u32(chosen_node, "riscv,kernel-
>> start",
>> + (u32 *)_start);
>> +#endif
>> +if (ret) {
>> +printf("Can't find kernel start address in
>> device
>> tree\n");
>> +return 0;
>> +}
>> +
>> +env_set_hex("kernel_start", kernel_start);
>> +
>> +return 0;
>> +}
>> diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-
>> riscv32_defconfig
>> index b55644378a..13dd53a550 100644
>> --- a/configs/qemu-riscv32_defconfig
>> +++ b/configs/qemu-riscv32_defconfig
>> @@ -4,4 +4,5 @@ CONFIG_NR_DRAM_BANKS=1
>> CONFIG_FIT=y
>> CONFIG_DISPLAY_CPUINFO=y
>> CONFIG_DISPLAY_BOARDINFO=y
>> +CONFIG_HUSH_PARSER=y
>> CONFIG_OF_PRIOR_STAGE=y
>> diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-
>> riscv64_defconfig
>> index a542ac4893..06eb3042fa 100644
>> --- a/configs/qemu-riscv64_defconfig
>> +++ b/configs/qemu-riscv64_defconfig
>> @@ -5,4 +5,5 @@ CONFIG_NR_DRAM_BANKS=1
>> CONFIG_FIT=y
>> CONFIG_DISPLAY_CPUINFO=y
>> CONFIG_DISPLAY_BOARDINFO=y
>> +CONFIG_HUSH_PARSER=y
>> CONFIG_OF_PRIOR_STAGE=y
>> diff --git a/include/configs/qemu-riscv.h
>> b/include/configs/qemu-
>> riscv.h
>> index ba6a18f2e6..7c88ba300a 100644
>> --- a/include/configs/qemu-riscv.h
>> +++ b/include/configs/qemu-riscv.h
>> @@ -21,7 +21,15 @@
>> #define CONFIG_ENV_SIZE SZ_4K
>>
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>> -"fdt_high=0x\0" \
>> +"fdt_high=0x8200\0" \
>> +"bootm_size=0x1000\0" \
>> "initrd_high=0x\0"
>>
>> +#define CONFIG_BOOTCOMMAND \
>> +"if env exists kernel_start; then " \
>> +"bootm ${kernel_start} - ${prior_stage_dtb};" \
>
> As Alexander Graf pointed out in reply to patch 24, we don't
> need
> the
> separate environment variable "prior_stage_dtb". I will replace
> it
> with
> "fdtcontroladdr" here and drop patch 24 in the next version.
Also, can you please enable distro boot? :)
Thanks,
Alex
>>>
>>> I just had a closer look at distro boot and it's actually
Re: [U-Boot] [PATCH v2 28/29] riscv: qemu: detect and boot the kernel passed by QEMU
Hi Bin,
On Sun, 2018-11-04 at 22:39 +0800, Bin Meng wrote:
> Hi Lukas,
>
> On Tue, Oct 30, 2018 at 8:57 PM Lukas Auer
> wrote:
> >
> > QEMU embeds the location of the kernel image in the device tree.
> > Store
> > this address in the environment as variable kernel_start and use it
> > in
> > CONFIG_BOOTCOMMAND to boot the kernel. Use the device tree passed
> > by the
> > prior boot stage to boot Linux.
> >
> > Signed-off-by: Lukas Auer
> > ---
> >
> > Changes in v2:
> > - Rebase onto u-boot-dm/next
> > - Boot Linux with the device tree provided by the prior boot stage
> >
> > board/emulation/qemu-riscv/Kconfig | 1 +
> > board/emulation/qemu-riscv/qemu-riscv.c | 29
> > +
> > configs/qemu-riscv32_defconfig | 1 +
> > configs/qemu-riscv64_defconfig | 1 +
> > include/configs/qemu-riscv.h| 10 -
> > 5 files changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/emulation/qemu-riscv/Kconfig
> > b/board/emulation/qemu-riscv/Kconfig
> > index 37a80db6a9..be5839b7db 100644
> > --- a/board/emulation/qemu-riscv/Kconfig
> > +++ b/board/emulation/qemu-riscv/Kconfig
> > @@ -29,5 +29,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > imply CMD_EXT2
> > imply CMD_EXT4
> > imply CMD_FAT
> > + imply BOARD_LATE_INIT
> >
> > endif
> > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> > b/board/emulation/qemu-riscv/qemu-riscv.c
> > index 2ce093e19a..ee20983095 100644
> > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > @@ -19,3 +19,32 @@ int board_init(void)
> >
> > return 0;
> > }
> > +
> > +int board_late_init(void)
> > +{
> > + ulong kernel_start;
> > + ofnode chosen_node;
> > + int ret;
> > +
> > + chosen_node = ofnode_path("/chosen");
> > + if (!ofnode_valid(chosen_node)) {
> > + printf("No chosen node found\n");
> > + return 0;
> > + }
> > +
> > +#ifdef CONFIG_ARCH_RV64I
> > + ret = ofnode_read_u64(chosen_node, "riscv,kernel-start",
> > + (u64 *)_start);
> > +#else
> > + ret = ofnode_read_u32(chosen_node, "riscv,kernel-start",
> > + (u32 *)_start);
> > +#endif
> > + if (ret) {
> > + printf("Can't find kernel start address in device
> > tree\n");
>
> I think we need use 'debug' instead of 'printf' here, for situation
> that kernel is not passed to QEMU.
>
Yes, you are right. What is the current best-practice here? Should I
use one of the pr_* functions or just debug?
Looking at the function, I am also not sure how useful the printf above
is (no chosen node found). I could replace it with the same text as in
the last printf. What do you think?
Thanks,
Lukas
> > + return 0;
> > + }
> > +
> > + env_set_hex("kernel_start", kernel_start);
> > +
> > + return 0;
> > +}
>
> [snip]
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] efi_selftest: add test for memory allocation
This unit test checks the following runtime services:
AllocatePages, FreePages, GetMemoryMap
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/Makefile | 1 +
lib/efi_selftest/efi_selftest_memory.c | 163 +
2 files changed, 164 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_memory.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 4b1c0bb84b1..743b4820449 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -27,6 +27,7 @@ efi_selftest_fdt.o \
efi_selftest_gop.o \
efi_selftest_loaded_image.o \
efi_selftest_manageprotocols.o \
+efi_selftest_memory.o \
efi_selftest_rtc.o \
efi_selftest_snp.o \
efi_selftest_textinput.o \
diff --git a/lib/efi_selftest/efi_selftest_memory.c
b/lib/efi_selftest/efi_selftest_memory.c
new file mode 100644
index 000..0623e8e62da
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_memory.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * efi_selftest_memory
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt
+ *
+ * This unit test checks the following runtime services:
+ * AllocatePages, FreePages, GetMemoryMap
+ */
+
+#include
+
+#define EFI_ST_NUM_PAGES 8
+
+static struct efi_boot_services *boottime;
+
+/**
+ * setup() - setup unit test
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * Return: EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ boottime = systable->boottime;
+
+ return EFI_ST_SUCCESS;
+}
+
+/**
+ * find_in_memory_map() - check matching memory map entry exists
+ *
+ * @memory_map:memory map
+ * @desc_size: number of memory map entries
+ * @addr: physical address to find in the map
+ * @type: expected memory type
+ * Return: EFI_ST_SUCCESS for success
+ */
+static int find_in_memory_map(efi_uintn_t map_size,
+ struct efi_mem_desc *memory_map,
+ efi_uintn_t desc_size,
+ u64 addr, int memory_type)
+{
+ efi_uintn_t i;
+ bool found = false;
+
+ for (i = 0; map_size; ++i, map_size -= desc_size) {
+ struct efi_mem_desc *entry = _map[i];
+
+ if (addr >= entry->physical_start &&
+ addr < entry->physical_start +
+ (entry->num_pages << EFI_PAGE_SHIFT)) {
+ if (found) {
+ efi_st_error("Duplicate memory map entry\n");
+ return EFI_ST_FAILURE;
+ }
+ found = true;
+ if (memory_type != entry->type) {
+ efi_st_error
+ ("Wrong memory type %d, expected %d\n",
+entry->type, memory_type);
+ return EFI_ST_FAILURE;
+ }
+ }
+ }
+ if (!found) {
+ efi_st_error("Missing memory map entry\n");
+ return EFI_ST_FAILURE;
+ }
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * execute() - execute unit test
+ *
+ * Return: EFI_ST_SUCCESS for success
+ */
+static int execute(void)
+{
+ u64 p1;
+ u64 p2;
+ efi_uintn_t map_size = 0;
+ efi_uintn_t map_key;
+ efi_uintn_t desc_size;
+ u32 desc_version;
+ struct efi_mem_desc *memory_map;
+ efi_status_t ret;
+
+ /* Allocate two page ranges with different memory type */
+ ret = boottime->allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+ EFI_RUNTIME_SERVICES_CODE,
+ EFI_ST_NUM_PAGES, );
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("AllocatePages did not return EFI_SUCCESS\n");
+ return EFI_ST_FAILURE;
+ }
+ ret = boottime->allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+ EFI_RUNTIME_SERVICES_DATA,
+ EFI_ST_NUM_PAGES, );
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("AllocatePages did not return EFI_SUCCESS\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /* Load memory map */
+ ret = boottime->get_memory_map(_size, NULL, _key, _size,
+ _version);
+ if (ret != EFI_BUFFER_TOO_SMALL) {
+ efi_st_error
+ ("GetMemoryMap did not return EFI_BUFFER_TOO_SMALL\n");
+ return EFI_ST_FAILURE;
+ }
+ /* Allocate extra space for newly allocated memory */
+ map_size += sizeof(struct efi_mem_desc);
+ ret = boottime->allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
+ (void **)_map);
+ if (ret !=
[U-Boot] [PATCH 0/3] fix GetMemoryMap()
The sandbox uses two different address rooms - one used internally by the sandbox and one usable for EFI. In efi_get_memory_map() we have to map the returned physical start addresses to EFI usable addresses. Add a unit test. Enable building the sandbox with CONFIG_EFI_SELFTEST=y. Heinrich Schuchardt (3): efi_loader: fix GetMemoryMap() efi_selftest: add test for memory allocation efi_selftest: building sandbox with EFI_SELFTEST configs/sandbox_defconfig | 1 - lib/efi_loader/efi_memory.c| 5 + lib/efi_selftest/Kconfig | 2 +- lib/efi_selftest/Makefile | 1 + lib/efi_selftest/efi_selftest_memory.c | 163 + 5 files changed, 170 insertions(+), 2 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_memory.c -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] efi_selftest: building sandbox with EFI_SELFTEST
Enable building the sandbox with CONFIG_EFI_SELFTEST. But do not select it by default as the network unit test may fail. Signed-off-by: Heinrich Schuchardt --- configs/sandbox_defconfig | 1 - lib/efi_selftest/Kconfig | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 2ce336fc81c..7edc27f2cde 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -24,7 +24,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_CMD_CPU=y CONFIG_CMD_LICENSE=y CONFIG_CMD_BOOTZ=y -CONFIG_CMD_BOOTEFI_SELFTEST=y # CONFIG_CMD_ELF is not set CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y diff --git a/lib/efi_selftest/Kconfig b/lib/efi_selftest/Kconfig index b52696778dd..59f9f36801c 100644 --- a/lib/efi_selftest/Kconfig +++ b/lib/efi_selftest/Kconfig @@ -1,6 +1,6 @@ config CMD_BOOTEFI_SELFTEST bool "Allow booting an EFI efi_selftest" - depends on CMD_BOOTEFI && !SANDBOX + depends on CMD_BOOTEFI imply FAT imply FAT_WRITE help -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] efi_loader: fix GetMemoryMap()
The sandbox uses two different address rooms - one used internally by the
sandbox and one usable for EFI.
Very unfortunately this has spilled into the EFI coding.
In efi_get_memory_map() we have to map the returned physical start
addresses to EFI usable addresses.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_memory.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 5bd4f4d7fc4..bbf174c7ef7 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -531,9 +531,14 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
memory_map = _map[map_entries - 1];
list_for_each(lhandle, _mem) {
struct efi_mem_list *lmem;
+ unsigned long len;
+ efi_physical_addr_t addr;
lmem = list_entry(lhandle, struct efi_mem_list, link);
*memory_map = lmem->desc;
+ len = memory_map->num_pages << EFI_PAGE_SHIFT;
+ addr = (uintptr_t)map_sysmem(memory_map->physical_start, len);
+ memory_map->physical_start = addr;
memory_map--;
}
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 4/6] efi: Split out test init/uninit into functions
HI Heinrich,
On 15 October 2018 at 11:34, Heinrich Schuchardt wrote:
> On 10/15/2018 04:17 PM, Simon Glass wrote:
>> The functions in bootefi are very long because they mix high-level code
>> and control with the low-level implementation. To help with this, create
>> functions which handle preparing for running the test and cleaning up
>> afterwards.
>>
>> Also shorten the awfully long variable names here.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v11: None
>> Changes in v9:
>> - Add comments to bootefi_test_prepare() about the memset()s
>>
>> Changes in v7: None
>> Changes in v5:
>> - Drop call to efi_init_obj_list() which is now done in do_bootefi()
>>
>> Changes in v4: None
>> Changes in v3:
>> - Add new patch to split out test init/uninit into functions
>>
>> cmd/bootefi.c | 90 +--
>> 1 file changed, 65 insertions(+), 25 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 82d755ceb31..88b8b0172db 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -454,6 +454,64 @@ exit:
>> return ret;
>> }
>>
>> +#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
>> +/**
>> + * bootefi_test_prepare() - prepare to run an EFI test
>> + *
>> + * This sets things up so we can call EFI functions. This involves preparing
>> + * the 'gd' pointer and setting up the load ed image data structures.
>> + *
>> + * @image: Pointer to a struct which will hold the loaded image info.
>> + *This struct will be inited by this function before use.
>> + * @obj: Pointer to a struct which will hold the loaded image object
>> + *This struct will be inited by this function before use.
>> + * @path: File path to the test being run (often just the test name with a
>> + *backslash before it
>> + * @test_func: Address of the test function that is being run
>> + * @return 0 if OK, -ve on error
>> + */
>> +static efi_status_t bootefi_test_prepare(struct efi_loaded_image **imagep,
>> + struct efi_loaded_image_obj **objp,
>> + const char *path, ulong test_func)
>> +{
>> + efi_status_t r;
>> +
>> + /* Construct a dummy device path */
>> + bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
>> + (uintptr_t)test_func,
>> + (uintptr_t)test_func);
>> + bootefi_image_path = efi_dp_from_file(NULL, 0, path);
>> + r = efi_setup_loaded_image(bootefi_device_path, bootefi_image_path,
>> +objp, imagep);
>> + if (r)
>> + return r;
>> + /*
>> + * gd lives in a fixed register which may get clobbered while we
>> execute
>> + * the payload. So save it here and restore it on every callback entry
>> + */
>> + efi_save_gd();
>> +
>> + /* Transfer environment variable efi_selftest as load options */
>> + set_load_options(*imagep, "efi_selftest");
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * bootefi_test_finish() - finish up after running an EFI test
>> + *
>> + * @image: Pointer to a struct which holds the loaded image info
>> + * @obj: Pointer to a struct which holds the loaded image object
>> + */
>> +static void bootefi_test_finish(struct efi_loaded_image *image,
>> + struct efi_loaded_image_obj *obj)
>> +{
>> + efi_restore_gd();
>> + free(image->load_options);
>> + efi_delete_handle(>parent);
>> +}
>> +#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
>> +
>> static int do_bootefi_bootmgr_exec(void)
>> {
>> struct efi_device_path *device_path, *file_path;
>> @@ -532,34 +590,16 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
>> argc, char * const argv[])
>> #endif
>> #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
>> if (!strcmp(argv[1], "selftest")) {
>
> Why not move the whole body of the if clause to a single separate
> function and do the same for 'hello'.
Because the goal here is to have a 'prepare' function and a 'finish'
function, to make it easier to see what is going on (which is that we
are running a test).
>
>> - struct efi_loaded_image_obj *image_handle;
>> - struct efi_loaded_image *loaded_image_info;
>> -
>> - /* Construct a dummy device path. */
>> - bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
>> - (uintptr_t)_selftest,
>> -
>> (uintptr_t)_selftest);
>> - bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
>> -
>> - r = efi_setup_loaded_image(bootefi_device_path,
>> -bootefi_image_path, _handle,
>> -_image_info);
>> - if (r != EFI_SUCCESS)
>> + struct efi_loaded_image_obj *obj;
>
> obj what? Use a speaking name: img_handle.
This is exactly
Re: [U-Boot] [PATCH v11 3/6] sandbox: smbios: Update to support sandbox
Hi Alex, On 22 October 2018 at 12:32, Alexander Graf wrote: > > > > > Am 22.10.2018 um 18:49 schrieb Simon Glass : > > > > Hi Alex, > > > >> On 19 October 2018 at 01:27, Alexander Graf wrote: > >> > >> > >>> On 19.10.18 05:25, Simon Glass wrote: > >>> Hi Alex, > >>> > On 16 October 2018 at 06:55, Alexander Graf wrote: > > > > On 15.10.18 16:17, Simon Glass wrote: > > At present this code casts addresses to pointers so cannot be used with > > sandbox. Update it to use mapmem instead. > > > > Signed-off-by: Simon Glass > > Unfortunately this won't work. The SMBIOS2 structure itself contains a > physical pointer to the target address (which in EFI lands really has to > be linear physical pointer). This pointer gets set based on "addr" in > write_smbios_table(): > > tables = addr; > [...] > se->struct_table_address = tables; > >>> > >>> Does that actually matter? We will never actually boot anything on > >>> sandbox that will use that address. > >> > >> Why not? We can boot the UEFI Shell today - and that can use the "address". > > > > OK, so UEFI shell uses the SMBIOS tables? I didn't know that. > > There is a command to print the contents of smbios tables - and that one does > use them :). OK, but it should work without any trouble due to my patch in dm/next. This seems like another reason to make sandbox use 32-bit pointers where possible. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] erase saved mmc-environment
Hi, i googled around but found no way to clear saved environment from mmc. currently i reset environment to the default and save it again env default -a;saveenv but how to clear the saved environment so that always the buildin gets loaded without manually reset it? regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 28/29] riscv: qemu: detect and boot the kernel passed by QEMU
Hi Lukas,
On Tue, Oct 30, 2018 at 8:57 PM Lukas Auer
wrote:
>
> QEMU embeds the location of the kernel image in the device tree. Store
> this address in the environment as variable kernel_start and use it in
> CONFIG_BOOTCOMMAND to boot the kernel. Use the device tree passed by the
> prior boot stage to boot Linux.
>
> Signed-off-by: Lukas Auer
> ---
>
> Changes in v2:
> - Rebase onto u-boot-dm/next
> - Boot Linux with the device tree provided by the prior boot stage
>
> board/emulation/qemu-riscv/Kconfig | 1 +
> board/emulation/qemu-riscv/qemu-riscv.c | 29 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv64_defconfig | 1 +
> include/configs/qemu-riscv.h| 10 -
> 5 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/board/emulation/qemu-riscv/Kconfig
> b/board/emulation/qemu-riscv/Kconfig
> index 37a80db6a9..be5839b7db 100644
> --- a/board/emulation/qemu-riscv/Kconfig
> +++ b/board/emulation/qemu-riscv/Kconfig
> @@ -29,5 +29,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply CMD_EXT2
> imply CMD_EXT4
> imply CMD_FAT
> + imply BOARD_LATE_INIT
>
> endif
> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> b/board/emulation/qemu-riscv/qemu-riscv.c
> index 2ce093e19a..ee20983095 100644
> --- a/board/emulation/qemu-riscv/qemu-riscv.c
> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> @@ -19,3 +19,32 @@ int board_init(void)
>
> return 0;
> }
> +
> +int board_late_init(void)
> +{
> + ulong kernel_start;
> + ofnode chosen_node;
> + int ret;
> +
> + chosen_node = ofnode_path("/chosen");
> + if (!ofnode_valid(chosen_node)) {
> + printf("No chosen node found\n");
> + return 0;
> + }
> +
> +#ifdef CONFIG_ARCH_RV64I
> + ret = ofnode_read_u64(chosen_node, "riscv,kernel-start",
> + (u64 *)_start);
> +#else
> + ret = ofnode_read_u32(chosen_node, "riscv,kernel-start",
> + (u32 *)_start);
> +#endif
> + if (ret) {
> + printf("Can't find kernel start address in device tree\n");
I think we need use 'debug' instead of 'printf' here, for situation
that kernel is not passed to QEMU.
> + return 0;
> + }
> +
> + env_set_hex("kernel_start", kernel_start);
> +
> + return 0;
> +}
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] riscv: cache: Implement i/dcache [status, enable, disable]
Hi Rick,
On Thu, Nov 1, 2018 at 12:10 PM Andes wrote:
>
> From: Rick Chen
>
> AndeStar RISC-V(V5) provide mcache_ctl register which
> can configure I/D cache as enabled or disabled.
>
> This CSR will be encapsulated by CONFIG_RISCV_NDS.
> If you want to configure cache on AndeStar V5
> AE350 platform. YOu can enable [*] AndeStar V5 ISA support
> by make menuconfig.
>
> This approach also provide the expansion when the
> vender specific features are going to join in.
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> arch/riscv/Kconfig | 8
> arch/riscv/cpu/ax25/Makefile | 1 +
> arch/riscv/cpu/ax25/cache.c| 89
> ++
> arch/riscv/cpu/ax25/cpu.c | 4 ++
> arch/riscv/cpu/qemu/cpu.c | 2 +-
> arch/riscv/cpu/start.S | 6 +++
> arch/riscv/include/asm/cache.h | 9 +
> arch/riscv/lib/cache.c | 30 +-
> 8 files changed, 138 insertions(+), 11 deletions(-)
> create mode 100644 arch/riscv/cpu/ax25/cache.c
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 371921b..a356729 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -74,4 +74,12 @@ config 32BIT
> config 64BIT
> bool
>
> +config RISCV_NDS
This needs better be moved to arch/riscv/cpu/ax25/Kconfig. I have a
patch to organize the Kconfig options in a hierarchy way @
http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commitdiff;h=5a650689410482907a37f77b2a4257d81bb4daa2;hp=11f2be3a168230d6e3afddb75b1a63adb0c1b838
> + bool "AndeStar V5 ISA support"
> + default n
nits: default n is not needed.
If we move this to arch/riscv/cpu/ax25/Kconfig, this option can be
selected by the board config.
> + help
> + Say Y here if you plan to run U-Boot on AndeStar v5
> + platforms and use some specific features which are
> + provided by Andes Technology AndeStar V5 Families.
> +
> endmenu
> diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
> index 2ab0342..318bacc 100644
> --- a/arch/riscv/cpu/ax25/Makefile
> +++ b/arch/riscv/cpu/ax25/Makefile
> @@ -4,3 +4,4 @@
> # Rick Chen, Andes Technology Corporation
>
> obj-y := cpu.o
> +obj-y += cache.o
> diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> new file mode 100644
> index 000..e0bcaa2
> --- /dev/null
> +++ b/arch/riscv/cpu/ax25/cache.c
> @@ -0,0 +1,89 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation
> + */
> +
> +#include
> +
> +void icache_enable(void)
> +{
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
There is no need to #ifdef here.
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "ori t0, t1, 0x1\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +#endif
> +}
> +
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 12/17] board_f: Use static print_cpuinfo if CONFIG_CPU is active
On Sun, Nov 4, 2018 at 4:18 PM Bin Meng wrote: > On Sun, Nov 4, 2018 at 4:51 AM Andy Shevchenko > wrote: > > On Sat, Nov 3, 2018 at 10:45 PM Andy Shevchenko > > wrote: > > > On Fri, Oct 12, 2018 at 6:34 PM Bin Meng wrote: > > > > + .flags = DM_FLAG_PRE_RELOC, > > > > > > This has to be done for all x86 boards I suppose? > > > Actually I don't see this in the v2018.11-rc3. > > > > Adding this to arch/x86/cpu/cpu_x86.c does NOT fix the problem! > > > > This patch needs to be applied on top of u-boot-dm/master. I already > sent out email to Simon for PR for v2018.11. Ah, I missed that. OK, I will give a shot next week. Thanks! -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] riscv: cache: Implement i/dcache [status, enable, disable]
Hi Rick,
On Thu, 2018-11-01 at 12:08 +0800, Andes wrote:
> From: Rick Chen
>
> AndeStar RISC-V(V5) provide mcache_ctl register which
> can configure I/D cache as enabled or disabled.
>
> This CSR will be encapsulated by CONFIG_RISCV_NDS.
> If you want to configure cache on AndeStar V5
> AE350 platform. YOu can enable [*] AndeStar V5 ISA support
> by make menuconfig.
>
> This approach also provide the expansion when the
> vender specific features are going to join in.
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> arch/riscv/Kconfig | 8
> arch/riscv/cpu/ax25/Makefile | 1 +
> arch/riscv/cpu/ax25/cache.c| 89
> ++
> arch/riscv/cpu/ax25/cpu.c | 4 ++
> arch/riscv/cpu/qemu/cpu.c | 2 +-
> arch/riscv/cpu/start.S | 6 +++
> arch/riscv/include/asm/cache.h | 9 +
> arch/riscv/lib/cache.c | 30 +-
> 8 files changed, 138 insertions(+), 11 deletions(-)
> create mode 100644 arch/riscv/cpu/ax25/cache.c
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 371921b..a356729 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -74,4 +74,12 @@ config 32BIT
> config 64BIT
> bool
>
> +config RISCV_NDS
> + bool "AndeStar V5 ISA support"
> + default n
> + help
> + Say Y here if you plan to run U-Boot on AndeStar v5
> + platforms and use some specific features which are
> + provided by Andes Technology AndeStar V5 Families.
> +
> endmenu
> diff --git a/arch/riscv/cpu/ax25/Makefile
> b/arch/riscv/cpu/ax25/Makefile
> index 2ab0342..318bacc 100644
> --- a/arch/riscv/cpu/ax25/Makefile
> +++ b/arch/riscv/cpu/ax25/Makefile
> @@ -4,3 +4,4 @@
> # Rick Chen, Andes Technology Corporation
>
> obj-y:= cpu.o
> +obj-y+= cache.o
> diff --git a/arch/riscv/cpu/ax25/cache.c
> b/arch/riscv/cpu/ax25/cache.c
> new file mode 100644
> index 000..e0bcaa2
> --- /dev/null
> +++ b/arch/riscv/cpu/ax25/cache.c
> @@ -0,0 +1,89 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation
> + */
> +
> +#include
> +
> +void icache_enable(void)
> +{
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "ori t0, t1, 0x1\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +#endif
> +}
> +
> +void icache_disable(void)
Just wondering, why do you not have the same #ifndef
CONFIG_SYS_ICACHE_OFF as above here?
> +{
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "andi t0, t1, ~0x1\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +}
> +
> +void dcache_enable(void)
> +{
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "ori t0, t1, 0x2\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +#endif
> +}
> +
> +void dcache_disable(void)
> +{
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "andi t0, t1, ~0x2\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +}
> +
> +int icache_status(void)
> +{
> + int ret = 0;
> +
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "andi %0, t1, 0x01\n\t"
> + : "=r" (ret)
> + :
> + : "memory"
> + );
> +#endif
> +
> + return ret;
> +}
> +
> +int dcache_status(void)
> +{
> + int ret = 0;
> +
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "andi %0, t1, 0x02\n\t"
> + : "=r" (ret)
> + :
> + : "memory"
> + );
> +#endif
> +
> + return ret;
> +}
> diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c
> index fddcc15..76689b2 100644
> --- a/arch/riscv/cpu/ax25/cpu.c
> +++ b/arch/riscv/cpu/ax25/cpu.c
> @@ -6,6 +6,7 @@
>
> /* CPU specific code */
> #include
> +#include
>
> /*
> * cleanup_before_linux() is called just before we call linux
> @@ -18,6 +19,9 @@ int cleanup_before_linux(void)
> disable_interrupts();
>
> /* turn off I/D-cache */
> + cache_flush();
> + icache_disable();
> + dcache_disable();
This is a separate change from the one described in the commit message,
please move this into a new patch.
I think we should do the same thing as ARM here. This is the
implementation on armv8, for example. This sequence is chosen so that
any new entries to the cache just before it is disabled get invalidated
as well.
/*
* Turn off I-cache and invalidate it
*/
icache_disable();
invalidate_icache_all();
/*
* turn off D-cache
* dcache_disable() in turn flushes the d-cache and disables MMU
*/
Re: [U-Boot] [PATCH v4 12/17] board_f: Use static print_cpuinfo if CONFIG_CPU is active
Hi Andy,
On Sun, Nov 4, 2018 at 4:51 AM Andy Shevchenko
wrote:
>
> On Sat, Nov 3, 2018 at 10:45 PM Andy Shevchenko
> wrote:
> >
> > On Fri, Oct 12, 2018 at 6:34 PM Bin Meng wrote:
> > > On Fri, Oct 12, 2018 at 10:00 PM Stefan Roese wrote:
> >
> > > diff --git a/arch/x86/cpu/baytrail/cpu.c b/arch/x86/cpu/baytrail/cpu.c
> > > index 56e9813..2eb9172 100644
> > > --- a/arch/x86/cpu/baytrail/cpu.c
> > > +++ b/arch/x86/cpu/baytrail/cpu.c
> > > @@ -203,4 +203,5 @@ U_BOOT_DRIVER(cpu_x86_baytrail_drv) = {
> > > .bind = cpu_x86_bind,
> > > .probe = cpu_x86_baytrail_probe,
> > > .ops= _x86_baytrail_ops,
> >
> > > + .flags = DM_FLAG_PRE_RELOC,
> >
> > This has to be done for all x86 boards I suppose?
> > Actually I don't see this in the v2018.11-rc3.
>
> Adding this to arch/x86/cpu/cpu_x86.c does NOT fix the problem!
>
This patch needs to be applied on top of u-boot-dm/master. I already
sent out email to Simon for PR for v2018.11.
> > > }
> > >
> > > This patch needs to be applied on top of u-boot-x86/dm-fixes. Could
> > > you please have a try?
> > >
> > > I was not aware Mario's changes broke the Baytrail boards too! I was
> > > only testing on QEMU x86 before.
> >
> > Not only.
> > Edison board is broken by this patch.
> >
> > This must be fixed before release, or better just to revert the patch ASAP.
>
> Please, revert, if there is no quick cure.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 28/29] riscv: qemu: detect and boot the kernel passed by QEMU
On Sat, 2018-11-03 at 20:33 +0100, Alexander Graf wrote:
>
> On 03.11.18 18:07, Auer, Lukas wrote:
> > On Tue, 2018-10-30 at 16:27 +0100, Alexander Graf wrote:
> > >
> > > On 30.10.18 16:02, Auer, Lukas wrote:
> > > > On Tue, 2018-10-30 at 13:55 +0100, Lukas Auer wrote:
> > > > > QEMU embeds the location of the kernel image in the device
> > > > > tree.
> > > > > Store
> > > > > this address in the environment as variable kernel_start and
> > > > > use
> > > > > it
> > > > > in
> > > > > CONFIG_BOOTCOMMAND to boot the kernel. Use the device tree
> > > > > passed
> > > > > by
> > > > > the
> > > > > prior boot stage to boot Linux.
> > > > >
> > > > > Signed-off-by: Lukas Auer
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - Rebase onto u-boot-dm/next
> > > > > - Boot Linux with the device tree provided by the prior boot
> > > > > stage
> > > > >
> > > > > board/emulation/qemu-riscv/Kconfig | 1 +
> > > > > board/emulation/qemu-riscv/qemu-riscv.c | 29
> > > > > +
> > > > > configs/qemu-riscv32_defconfig | 1 +
> > > > > configs/qemu-riscv64_defconfig | 1 +
> > > > > include/configs/qemu-riscv.h| 10 -
> > > > > 5 files changed, 41 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/board/emulation/qemu-riscv/Kconfig
> > > > > b/board/emulation/qemu-riscv/Kconfig
> > > > > index 37a80db6a9..be5839b7db 100644
> > > > > --- a/board/emulation/qemu-riscv/Kconfig
> > > > > +++ b/board/emulation/qemu-riscv/Kconfig
> > > > > @@ -29,5 +29,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > imply CMD_EXT2
> > > > > imply CMD_EXT4
> > > > > imply CMD_FAT
> > > > > + imply BOARD_LATE_INIT
> > > > >
> > > > > endif
> > > > > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> > > > > b/board/emulation/qemu-riscv/qemu-riscv.c
> > > > > index 2ce093e19a..ee20983095 100644
> > > > > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > > > > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > > > > @@ -19,3 +19,32 @@ int board_init(void)
> > > > >
> > > > > return 0;
> > > > > }
> > > > > +
> > > > > +int board_late_init(void)
> > > > > +{
> > > > > + ulong kernel_start;
> > > > > + ofnode chosen_node;
> > > > > + int ret;
> > > > > +
> > > > > + chosen_node = ofnode_path("/chosen");
> > > > > + if (!ofnode_valid(chosen_node)) {
> > > > > + printf("No chosen node found\n");
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > +#ifdef CONFIG_ARCH_RV64I
> > > > > + ret = ofnode_read_u64(chosen_node, "riscv,kernel-
> > > > > start",
> > > > > + (u64 *)_start);
> > > > > +#else
> > > > > + ret = ofnode_read_u32(chosen_node, "riscv,kernel-
> > > > > start",
> > > > > + (u32 *)_start);
> > > > > +#endif
> > > > > + if (ret) {
> > > > > + printf("Can't find kernel start address in
> > > > > device
> > > > > tree\n");
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + env_set_hex("kernel_start", kernel_start);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-
> > > > > riscv32_defconfig
> > > > > index b55644378a..13dd53a550 100644
> > > > > --- a/configs/qemu-riscv32_defconfig
> > > > > +++ b/configs/qemu-riscv32_defconfig
> > > > > @@ -4,4 +4,5 @@ CONFIG_NR_DRAM_BANKS=1
> > > > > CONFIG_FIT=y
> > > > > CONFIG_DISPLAY_CPUINFO=y
> > > > > CONFIG_DISPLAY_BOARDINFO=y
> > > > > +CONFIG_HUSH_PARSER=y
> > > > > CONFIG_OF_PRIOR_STAGE=y
> > > > > diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-
> > > > > riscv64_defconfig
> > > > > index a542ac4893..06eb3042fa 100644
> > > > > --- a/configs/qemu-riscv64_defconfig
> > > > > +++ b/configs/qemu-riscv64_defconfig
> > > > > @@ -5,4 +5,5 @@ CONFIG_NR_DRAM_BANKS=1
> > > > > CONFIG_FIT=y
> > > > > CONFIG_DISPLAY_CPUINFO=y
> > > > > CONFIG_DISPLAY_BOARDINFO=y
> > > > > +CONFIG_HUSH_PARSER=y
> > > > > CONFIG_OF_PRIOR_STAGE=y
> > > > > diff --git a/include/configs/qemu-riscv.h
> > > > > b/include/configs/qemu-
> > > > > riscv.h
> > > > > index ba6a18f2e6..7c88ba300a 100644
> > > > > --- a/include/configs/qemu-riscv.h
> > > > > +++ b/include/configs/qemu-riscv.h
> > > > > @@ -21,7 +21,15 @@
> > > > > #define CONFIG_ENV_SIZE SZ_4K
> > > > >
> > > > > #define CONFIG_EXTRA_ENV_SETTINGS \
> > > > > - "fdt_high=0x\0" \
> > > > > + "fdt_high=0x8200\0" \
> > > > > + "bootm_size=0x1000\0" \
> > > > > "initrd_high=0x\0"
> > > > >
> > > > > +#define CONFIG_BOOTCOMMAND \
> > > > > + "if env exists kernel_start; then " \
> > > > > + "bootm ${kernel_start} - ${prior_stage_dtb};" \
> > > >
> > > > As Alexander Graf pointed out in reply to patch 24, we don't
> > > > need
> > > > the
> > > > separate environment variable "prior_stage_dtb".
Re: [U-Boot] mt7623 bootup example
Just to be clear...i tested v2 patches on rc1 (https://github.com/frank-w/u-boot/tree/bpi-r2_v2) they working well. v3 have additional depencies (swig,python-dev same on rc1) and bootargs seems not to be passed to kernel (rc1=bpi-r2_v3_old and rc3 = bpi-r2_v3) > Gesendet: Samstag, 03. November 2018 um 09:46 Uhr > Von: "Frank Wunderlich" > An: s...@chromium.org, "Ryder Lee" > Cc: u-boot@lists.denx.de > Betreff: [U-Boot] mt7623 bootup example > > Hi Simon, hi Ryder, > > i tried Patches so far, they are working well > > https://patchwork.ozlabs.org/patch/992398/ > > here my github-repo with steps to build: > > https://github.com/frank-w/u-boot > > there is a build.sh, which compiles uboot the common way with some additions > like bootmenu and full environment to load a kernel on BPI-R2 > > here are instructions how to prepare SD-Card for boot-up: > > https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:storage#extended_boot-headers > > as you see you need 3 Headers on SD-Card (SDMMC_BOOT, BRLYT, Preloader) and > the uboot.bin for SD-Card. on emmc imho preloader in boot0-block and uboot on > main-Partition is enough for uboot to boot > > Source: > https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:uboot#update_uboot > > btw. @ryder.lee you have a small typo in the readme: > Boorom => Bootrom (2 times) > > maybe you can add Infos above from my wiki. Btw. how far is the > ethernet-driver? then i can replace my 2014-uboot ;) > > regards Frank > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-sh/master
The following changes since commit fdaccfeb5e03e18c05be386b8a7c6be02be2cf15: Merge branch 'master' of git://git.denx.de/u-boot-socfpga (2018-10-31 17:15:55 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to a376dde1deb9cc42e3804b9c654f873c936cc8d4: mmc: tmio: sdhi: Merge DTCNTL access into single register write (2018-11-02 16:07:04 +0100) Marek Vasut (12): pinctrl: renesas: Fix DRV register offset pinctrl: renesas: Add POCCTRL handling to r8a77990 ARM: rmobile: Generate fitting mem_map on Gen3 mmc: tmio: Simplify pinmux handling mmc: tmio: Improve error handling mmc: tmio: Silence transfer errors when tuning mmc: tmio: Configure clock before any other IOS mmc: tmio: Preinitialize regulator to 3.3V mmc: tmio: sdhi: Touch SCC only when UHS capable mmc: tmio: sdhi: Clear HS400 settings when resetting SCC mmc: tmio: sdhi: Implement waiting for DAT0 line state mmc: tmio: sdhi: Merge DTCNTL access into single register write arch/arm/mach-rmobile/cpu_info.c | 3 +++ arch/arm/mach-rmobile/memmap-gen3.c| 89 - drivers/mmc/renesas-sdhi.c | 48 +++- drivers/mmc/tmio-common.c | 76 +--- drivers/pinctrl/renesas/pfc-r8a77990.c | 34 -- drivers/pinctrl/renesas/pfc.c | 2 +- 6 files changed, 196 insertions(+), 56 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
