[U-Boot] [PATCHv3] ARM: zynq: Add configuration for Z-turn board
From: Anton Gerasimov
Basic (PS-only) configuration based on Vivado board files by
Sergiusz Bazanski
Signed-off-by: Anton Gerasimov
---
board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c | 281
1 file changed, 281 insertions(+)
create mode 100644 board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
diff --git a/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
new file mode 100644
index 00..d4f0ee796f
--- /dev/null
+++ b/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) Xilinx, Inc.
+ */
+
+#include
+
+static unsigned long ps7_pll_init_data[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000110, 0x0030U, 0x000FA220U),
+ EMIT_MASKWRITE(0xF8000100, 0x0007F000U, 0x00028000U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000120, 0x1F003F30U, 0x1F000200U),
+ EMIT_MASKWRITE(0xF8000114, 0x0030U, 0x0012C220U),
+ EMIT_MASKWRITE(0xF8000104, 0x0007F000U, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000124, 0xFFF3U, 0x0C23U),
+ EMIT_MASKWRITE(0xF8000118, 0x0030U, 0x001452C0U),
+ EMIT_MASKWRITE(0xF8000108, 0x0007F000U, 0x0001E000U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000108, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000108, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0004U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U, 0xU),
+ EMIT_WRITE(0xF804, 0x767BU),
+ EMIT_EXIT(),
+};
+
+static unsigned long ps7_clock_init_data[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000128, 0x03F03F01U, 0x00700F01U),
+ EMIT_MASKWRITE(0xF8000138, 0x0011U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000140, 0x03F03F71U, 0x00100801U),
+ EMIT_MASKWRITE(0xF800014C, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0xF8000150, 0x3F33U, 0x1401U),
+ EMIT_MASKWRITE(0xF8000154, 0x3F33U, 0x0A03U),
+ EMIT_MASKWRITE(0xF800015C, 0x03F03F33U, 0x00200501U),
+ EMIT_MASKWRITE(0xF8000160, 0x007F007FU, 0xU),
+ EMIT_MASKWRITE(0xF8000168, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0xF8000170, 0x03F03F30U, 0x00200500U),
+ EMIT_MASKWRITE(0xF8000180, 0x03F03F30U, 0x00400500U),
+ EMIT_MASKWRITE(0xF80001C4, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF800012C, 0x01FFCCCDU, 0x01FD044DU),
+ EMIT_WRITE(0xF804, 0x767BU),
+ EMIT_EXIT(),
+};
+
+static unsigned long ps7_ddr_init_data[] = {
+ EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0080U),
+ EMIT_MASKWRITE(0xF8006004, 0x0007U, 0x1082U),
+ EMIT_MASKWRITE(0xF8006008, 0x03FFU, 0x03C0780FU),
+ EMIT_MASKWRITE(0xF800600C, 0x03FFU, 0x02001001U),
+ EMIT_MASKWRITE(0xF8006010, 0x03FFU, 0x00014001U),
+ EMIT_MASKWRITE(0xF8006014, 0x001FU, 0x0004285BU),
+ EMIT_MASKWRITE(0xF8006018, 0xF7FFU, 0x44E458D3U),
+ EMIT_MASKWRITE(0xF800601C, 0xU, 0x7282BCE5U),
+ EMIT_MASKWRITE(0xF8006020, 0x7FDCU, 0x270872D0U),
+ EMIT_MASKWRITE(0xF8006024, 0x0FC3U, 0xU),
+ EMIT_MASKWRITE(0xF8006028, 0x3FFFU, 0x2007U),
+ EMIT_MASKWRITE(0xF800602C, 0xU, 0x0008U),
+ EMIT_MASKWRITE(0xF8006030, 0xU, 0x00040B30U),
+ EMIT_MASKWRITE(0xF8006034, 0x13FF3FFFU, 0x000116D4U),
+ EMIT_MASKWRITE(0xF8006038, 0x0003U, 0xU),
+ EMIT_MASKWRITE(0xF800603C, 0x000FU, 0x0777U),
+ EMIT_MASKWRITE(0xF8006040, 0xU, 0xFFF0U),
+ EMIT_MASKWRITE(0xF8006044, 0x0FFFU, 0x0F66U),
+ EMIT_MASKWRITE(0xF8006048, 0x0003F03FU, 0x0003C008U),
+ EMIT_MASKWRITE(0xF8006050, 0xFF0F8FFFU, 0x77010800U),
+ EMIT_MASKWRITE(0xF8006058, 0x0001U, 0xU),
+ EMIT_MASKWRITE(0xF800605C, 0xU, 0x5003U),
+ EMIT_MASKWRITE(0xF8006060, 0x17FFU, 0x003EU),
+ EMIT_MASKWRITE(0xF8006064, 0x00021FE0U, 0x0002U),
+ EMIT_MASKWRITE(0xF8006068, 0x03FFU, 0x00284141U),
+ EMIT_MASKWRITE(0xF800606C, 0xU, 0x1610U),
+ EMIT_MASKWRITE(0xF8006078, 0x03FFU, 0x00466111U),
+ EMIT_MASKWRITE(0xF800607C, 0x000FU, 0x0003U),
+ EMIT_MASKWRITE(0xF80060A4, 0xU
[U-Boot] [PATCHv2 1/1] Basic (PS-only) configuration based on Vivado board files by Sergiusz Bazanski
From: Anton Gerasimov
Signed-off-by: Anton Gerasimov
---
board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c | 814
1 file changed, 814 insertions(+)
create mode 100644 board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
diff --git a/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
new file mode 100644
index 00..ef9b77a0dc
--- /dev/null
+++ b/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
@@ -0,0 +1,814 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) Xilinx, Inc.
+ */
+
+#include
+
+static unsigned long ps7_pll_init_data_3_0[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000110, 0x0030U, 0x000FA220U),
+ EMIT_MASKWRITE(0xF8000100, 0x0007F000U, 0x00028000U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000120, 0x1F003F30U, 0x1F000200U),
+ EMIT_MASKWRITE(0xF8000114, 0x0030U, 0x0012C220U),
+ EMIT_MASKWRITE(0xF8000104, 0x0007F000U, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000124, 0xFFF3U, 0x0C23U),
+ EMIT_MASKWRITE(0xF8000118, 0x0030U, 0x001452C0U),
+ EMIT_MASKWRITE(0xF8000108, 0x0007F000U, 0x0001E000U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000108, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000108, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0004U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U, 0xU),
+ EMIT_WRITE(0xF804, 0x767BU),
+ EMIT_EXIT(),
+};
+
+static unsigned long ps7_clock_init_data_3_0[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000128, 0x03F03F01U, 0x00700F01U),
+ EMIT_MASKWRITE(0xF8000138, 0x0011U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000140, 0x03F03F71U, 0x00100801U),
+ EMIT_MASKWRITE(0xF800014C, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0xF8000150, 0x3F33U, 0x1401U),
+ EMIT_MASKWRITE(0xF8000154, 0x3F33U, 0x0A03U),
+ EMIT_MASKWRITE(0xF800015C, 0x03F03F33U, 0x00200501U),
+ EMIT_MASKWRITE(0xF8000160, 0x007F007FU, 0xU),
+ EMIT_MASKWRITE(0xF8000168, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0xF8000170, 0x03F03F30U, 0x00200500U),
+ EMIT_MASKWRITE(0xF8000180, 0x03F03F30U, 0x00400500U),
+ EMIT_MASKWRITE(0xF80001C4, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF800012C, 0x01FFCCCDU, 0x01FD044DU),
+ EMIT_WRITE(0xF804, 0x767BU),
+ EMIT_EXIT(),
+};
+
+static unsigned long ps7_ddr_init_data_3_0[] = {
+ EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0080U),
+ EMIT_MASKWRITE(0xF8006004, 0x0007U, 0x1082U),
+ EMIT_MASKWRITE(0xF8006008, 0x03FFU, 0x03C0780FU),
+ EMIT_MASKWRITE(0xF800600C, 0x03FFU, 0x02001001U),
+ EMIT_MASKWRITE(0xF8006010, 0x03FFU, 0x00014001U),
+ EMIT_MASKWRITE(0xF8006014, 0x001FU, 0x0004285BU),
+ EMIT_MASKWRITE(0xF8006018, 0xF7FFU, 0x44E458D3U),
+ EMIT_MASKWRITE(0xF800601C, 0xU, 0x7282BCE5U),
+ EMIT_MASKWRITE(0xF8006020, 0x7FDCU, 0x270872D0U),
+ EMIT_MASKWRITE(0xF8006024, 0x0FC3U, 0xU),
+ EMIT_MASKWRITE(0xF8006028, 0x3FFFU, 0x2007U),
+ EMIT_MASKWRITE(0xF800602C, 0xU, 0x0008U),
+ EMIT_MASKWRITE(0xF8006030, 0xU, 0x00040B30U),
+ EMIT_MASKWRITE(0xF8006034, 0x13FF3FFFU, 0x000116D4U),
+ EMIT_MASKWRITE(0xF8006038, 0x0003U, 0xU),
+ EMIT_MASKWRITE(0xF800603C, 0x000FU, 0x0777U),
+ EMIT_MASKWRITE(0xF8006040, 0xU, 0xFFF0U),
+ EMIT_MASKWRITE(0xF8006044, 0x0FFFU, 0x0F66U),
+ EMIT_MASKWRITE(0xF8006048, 0x0003F03FU, 0x0003C008U),
+ EMIT_MASKWRITE(0xF8006050, 0xFF0F8FFFU, 0x77010800U),
+ EMIT_MASKWRITE(0xF8006058, 0x0001U, 0xU),
+ EMIT_MASKWRITE(0xF800605C, 0xU, 0x5003U),
+ EMIT_MASKWRITE(0xF8006060, 0x17FFU, 0x003EU),
+ EMIT_MASKWRITE(0xF8006064, 0x00021FE0U, 0x0002U),
+ EMIT_MASKWRITE(0xF8006068, 0x03FFU, 0x00284141U),
+ EMIT_MASKWRITE(0xF800606C, 0xU, 0x1610U),
+ EMIT_MASKWRITE(0xF8006078, 0x03FFU, 0x00466111U),
+ EMIT_MASKWRITE(0xF800607C, 0x000FU, 0x0003U),
+ EMIT_MASKWRITE(0xF80060A4, 0xU, 0x10200802U),
+ EMIT_MASKWRITE(0xF80060A8, 0x0FFFU, 0x0690CB73U
[U-Boot] [PATCHv2 0/1] Add ps7_init_gpl.c for Z-turn board
From: Anton Gerasimov Device tree and defconfig are already in U-boot. I've done basic testing (i.e. it boots). Fixed warnings/errors from checkpatch.pl Anton Gerasimov (1): Basic (PS-only) configuration based on Vivado board files by Sergiusz Bazanski board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c | 814 1 file changed, 814 insertions(+) create mode 100644 board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] board: raspberrypi: add serial and revision to the device tree
On 2/20/19 6:15 PM, Stephen Warren wrote: On 2/20/19 10:04 AM, Alexander Graf wrote: On 02/20/2019 05:59 PM, Stephen Warren wrote: On 2/20/19 5:09 AM, Anton Gerasimov wrote: Raspberry Pi bootloader adds this node to fdt, but if u-boot script doesn't reuse the tree provided by it, this information is lost. Revision and serial are displayed in /proc/cpuinfo after boot. Are these properties documented in the upstream Linux kernel in Documentation/devicetree/bindings/? If so, this patch is fine. If not, we should not merge it, since we don't want to pollute the DT with non-standard properties (or: add this to the upstream kernel DT documentation, and then apply this patch once the doc update is approved upstream). Hm, it almost looks like it's a downstream hack. Unfortunately as U-Boot we're in this really weird place where people may want to use it to load downstream kernels. For similar things in L4T's[1] downstream fork of U-Boot, what I've done is this: a) U-Boot implements the code to set various DT properties, or copy them from the DT provided by whatever-runs-before-U-Boot to the DT U-Boot provides to whatever-runs-after-U-Boot. b) Whether U-Boot actually does this set/copy operation is determined by the value of an environment variable. c) The default U-Boot environment enables all set/copy operations required by L4T. d) If someone wants a "pure upstream" DT passed to the kernel, they can edit the environment to disable those operations, and save the environment. This allows users to select which kind of DT they want passed to the kernel. For example, see dt-edit.* at: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/u-boot.git;a=tree;f=arch/arm/mach-tegra;h=d9a17eec4f0271cdc3932f0cee8c39fb17197a0b;hb=l4t/l4t-r27.1 ... and MEM_LAYOUT_ENV_SETTINGS in: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/u-boot.git;a=blob;f=include/configs/tegra210-common.h;h=156b280a00f37f811c96d0006fe2b87bdeb07e74;hb=l4t/l4t-r27.1 I'm pretty sure the value of fdt_copy_node_paths was longer in some release, but I don't remember which one, so can't quickly find it. And yes, the links above are about copying nodes between DTs, but you can imagine a similar flag env. var. for the feature in this current patch too. [1] NVIDIA Linux for Tegra. Yes, that's something implemented in linux-raspberrypi [1] only. My use case ([2], [3], or more specifically [4]) for u-boot on Raspberry Pi includes letting the user update the device tree as a part of their FIT image, so using the device tree provided by the primary bootloader would not quite work here. But I understand that it might not quite belong to the u-boot code base, so this functionality might continue its existence as a patch applied in meta-updater. As for polluting the device tree, it just imitates the pollution already done by the proprietary Raspberry Pi bootloader, so I don't think it should be a problem. [1] https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/mach-bcm/board_bcm2835.c#L29 [2] https://github.com/advancedtelematic/meta-updater/ [3] https://github.com/advancedtelematic/meta-updater-raspberrypi/ [4] https://github.com/advancedtelematic/meta-updater-raspberrypi/blob/master/recipes-bsp/u-boot-otascript/u-boot-otascript/uEnv.txt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/1] Pass board revision and serial number to the
Raspberry Pi proprietary bootloader adds this information to the device tree to finally land in /proc/cpuinfo. It is then used by some userspace tools. In particular `gpio` tool from WiringPi suite would use the wrong register mapping when this information is missing from /proc/cpuinfo. Anton Gerasimov (1): board: raspberrypi: add serial and revision to the device tree board/raspberrypi/rpi/rpi.c | 35 +-- 1 file changed, 33 insertions(+), 2 deletions(-) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] board: raspberrypi: add serial and revision to the device tree
Raspberry Pi bootloader adds this node to fdt, but if u-boot script
doesn't reuse the tree provided by it, this information is lost.
Revision and serial are displayed in /proc/cpuinfo after boot.
Suggested-By: Ricardo Salveti
Reported-by: Karl Eaves
Signed-off-by: Anton Gerasimov
---
board/raspberrypi/rpi/rpi.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 153a1fdcb7..f6a2cdfbfd 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -238,6 +238,8 @@ static uint32_t rev_scheme;
static uint32_t rev_type;
static const struct rpi_model *model;
+static uint64_t serial;
+
#ifdef CONFIG_ARM64
static struct mm_region bcm2837_mem_map[] = {
{
@@ -381,8 +383,8 @@ static void set_serial_number(void)
return;
}
- snprintf(serial_string, sizeof(serial_string), "%016llx",
-msg->get_board_serial.body.resp.serial);
+ serial = msg->get_board_serial.body.resp.serial;
+ snprintf(serial_string, sizeof(serial_string), "%016llx", serial);
env_set("serial#", serial_string);
}
@@ -475,6 +477,33 @@ void *board_fdt_blob_setup(void)
return (void *)fw_dtb_pointer;
}
+static int ft_add_revision_info(void *blob) {
+ int off;
+ int ret;
+
+ off = fdt_subnode_offset(blob, 0, "system");
+
+ if (off < 0) {
+ off = fdt_add_subnode(blob, 0, "system");
+ if (off < 0)
+ return -1;
+ }
+
+ if (!fdt_getprop(blob, off, "linux,serial", NULL)) {
+ ret = fdt_setprop_u64(blob, off, "linux,serial", serial);
+ if (ret < 0)
+ return -1;
+ }
+
+ if (!fdt_getprop(blob, off, "linux,revision", NULL)) {
+ ret = fdt_setprop_u32(blob, off, "linux,revision", revision);
+ if (ret < 0)
+ return -1;
+ }
+
+ return 0;
+}
+
int ft_board_setup(void *blob, bd_t *bd)
{
/*
@@ -484,6 +513,8 @@ int ft_board_setup(void *blob, bd_t *bd)
*/
lcd_dt_simplefb_add_node(blob);
+ ft_add_revision_info(blob);
+
#ifdef CONFIG_EFI_LOADER
/* Reserve the spin table */
efi_add_memory_map(0, 1, EFI_RESERVED_MEMORY_TYPE, 0);
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] zynq: Kconfig: extend the bootstrap malloc() pool
Hi Michal, I understand all of this but will be good to know what consumes that 0x5xx space and if we mark nodes properly that maybe something is not used and we should remove that marking. It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd 0xXXX, etc. measuring only the memory consumed in device_bind_common, I've got the following results (in decimal): root_driver: 108 mod_exp_sw: 108 amba: 120 serial@e000 aka uart0: 112 serial@e0001000 aka uart1: 88 spi@e000d000 aka qspi: 120 sdhci@e010 aka mmc0: 455 sd...@e010.blk: 208 slcr@f800: 96 clkc@100: 72 (total) 1487 = 0x5cf of 0x600 So the most memory is being consumed by mmc0 (not quite sure what is this '.blk' device, but it is probably also required), but it's not dominating, other seemingly useful devices also have a decent share. Thanks, Anton ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2] zynq: Kconfig: extend the bootstrap malloc() pool
Most of the memory is being consumed by device binding code, more space needed for other data structures. Z-turn board has already hit the limit, others may follow soon. Signed-off-by: Anton Gerasimov --- arch/arm/mach-zynq/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig index a599ed63ee..21dfebf5c0 100644 --- a/arch/arm/mach-zynq/Kconfig +++ b/arch/arm/mach-zynq/Kconfig @@ -55,7 +55,7 @@ config SYS_CONFIG_NAME will be used for board configuration. config SYS_MALLOC_F_LEN - default 0x600 + default 0x800 config SYS_MALLOC_LEN default 0x140 -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] zynq: Kconfig: extend the bootstrap malloc() pool
I have not a problem with this change but it has to be done based on more information. It means you should look what requires that memory and if make sense that these components need it at that time. Thank you for the advice, that was quite fruitful. So most of the heap (0x5f4 of 0x600) before the relocation is being consumed in device_bind_common function which binds device tree entries to the drivers. If I remove 'u-boot,dm-pre-alloc' from uart0 node, that is not being used as far as I can see, it drops to 0x5a0, which lets the board boot, but still looks pretty tight. So maybe it's worth extending the heap anyway unless you need more information to take the decision. Thanks, Anton ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] zynq: Kconfig: extend the bootstrap malloc() pool
Signed-off-by: Anton Gerasimov --- arch/arm/mach-zynq/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig index a599ed63ee..21dfebf5c0 100644 --- a/arch/arm/mach-zynq/Kconfig +++ b/arch/arm/mach-zynq/Kconfig @@ -55,7 +55,7 @@ config SYS_CONFIG_NAME will be used for board configuration. config SYS_MALLOC_F_LEN - default 0x600 + default 0x800 config SYS_MALLOC_LEN default 0x140 -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/1] Extend malloc() pool for Zynq devices
I'm getting -ENOMEM on Z-Turn board already, other boards are probably still allright if no one complains, but might hit the limit soon. Anton Gerasimov (1): zynq: Kconfig: extend the bootstrap malloc() pool arch/arm/mach-zynq/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Writes to FAT broken by bcm2835 sdhost driver
Thank you, I should have checked the master instead of relying on what's in poky. Unrelated: now I can't load FIT image, but I don't have enough data do tell what the reason is yet. Thanks, Anton On 06/28/2018 11:49 AM, Alexander Graf wrote: > On 06/28/2018 10:53 AM, Anton Gerasimov wrote: >> [resending, forgot to subscribe from this address] >> >> Hi, >> >> For some reasons I need to save environment on RaspberryPi 3 and it >> worked well for me in older versions of u-boot, but stopped working in >> newer ones. Using bisect I figured out that the commits responsible for >> that were c8a73a26d6dd9b7d489e66529fe1412425d8f2d1 and >> caf2233b281c03e3e359061a3dfa537d8a25c273, introducing sdhost and pinctrl >> drivers respectively. >> >> Versions before these two work well wrt. writing to FAT/saving the >> environment. >> >> After these patches when compiled with rpi_3_32b_defconfig, reading >> works well, but fatwrite gives >> >> wait_transfer_complete - still waiting after 10001 retries >> >> and saveenv >> >> fsm 1, hsts 0001 > > This should be fixed in 2018.07. Please try to run with latest git. > > > Alex > -- ATS Advanced Telematic Systems was acquired by HERE Technologies Anton Gerasimov Software Engineer HERE Technologies Kantstrasse 162, 10623 Berlin, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Writes to FAT broken by bcm2835 sdhost driver
Hi, For some reasons I need to save environment on RaspberryPi 3 and it worked well for me in older versions of u-boot, but stopped working in newer ones. Using bisect I figured out that the commits responsible for that were c8a73a26d6dd9b7d489e66529fe1412425d8f2d1 and caf2233b281c03e3e359061a3dfa537d8a25c273, introducing sdhost and pinctrl drivers respectively. Versions before these two work well wrt. writing to FAT/saving the environment. After these patches when compiled with rpi_3_32b_defconfig, reading works well, but fatwrite gives wait_transfer_complete - still waiting after 10001 retries and saveenv fsm 1, hsts 0001 When I try to compile with CONFIG_MMC_BCM2835=n (CONFIG_MMC_SDHCI_BCM2835 is still enabled), neither read nor write works: Saving Environment to FAT... Card did not respond to voltage select! ** Bad device mmc 0 ** Failed (1) Finally with CONFIG_PINCTRL=n u-boot doesn't compile at all (not sure if it was intended behavior): serial_bcm283x_mu.c:162: undefined reference to `pinctrl_get_gpio_mux' serial_bcm283x_pl011.c:30: undefined reference to `pinctrl_get_gpio_mux' Would be grateful for any help with these issues. Best regargs, Anton Gerasimov ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Writes to FAT broken by bcm2835 sdhost driver
[resending, forgot to subscribe from this address] Hi, For some reasons I need to save environment on RaspberryPi 3 and it worked well for me in older versions of u-boot, but stopped working in newer ones. Using bisect I figured out that the commits responsible for that were c8a73a26d6dd9b7d489e66529fe1412425d8f2d1 and caf2233b281c03e3e359061a3dfa537d8a25c273, introducing sdhost and pinctrl drivers respectively. Versions before these two work well wrt. writing to FAT/saving the environment. After these patches when compiled with rpi_3_32b_defconfig, reading works well, but fatwrite gives wait_transfer_complete - still waiting after 10001 retries and saveenv fsm 1, hsts 0001 When I try to compile with CONFIG_MMC_BCM2835=n (CONFIG_MMC_SDHCI_BCM2835 is still enabled), neither read nor write works: Saving Environment to FAT... Card did not respond to voltage select! ** Bad device mmc 0 ** Failed (1) Finally with CONFIG_PINCTRL=n u-boot doesn't compile at all (not sure if it was intended behavior): serial_bcm283x_mu.c:162: undefined reference to `pinctrl_get_gpio_mux' serial_bcm283x_pl011.c:30: undefined reference to `pinctrl_get_gpio_mux' Would be grateful for any help with these issues. Best regargs, Anton Gerasimov ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv3 2/2] ARM: dts: zynq: Rename dts for Z-turn board
Makes naming in line with other Zynq boards.
Signed-off-by: Anton Gerasimov
---
arch/arm/dts/Makefile| 2 +-
arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} | 0
configs/zynq_z_turn_defconfig| 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} (100%)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 20a4c37d48..83aa2f4df4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -143,7 +143,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
zynq-zed.dtb \
- zynq-zturn-myir.dtb \
+ zynq-zturn.dtb \
zynq-zybo.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
zynqmp-ep108.dtb\
diff --git a/arch/arm/dts/zynq-zturn-myir.dts b/arch/arm/dts/zynq-zturn.dts
similarity index 100%
rename from arch/arm/dts/zynq-zturn-myir.dts
rename to arch/arm/dts/zynq-zturn.dts
diff --git a/configs/zynq_z_turn_defconfig b/configs/zynq_z_turn_defconfig
index 7a51b85ac8..1270e30cab 100644
--- a/configs/zynq_z_turn_defconfig
+++ b/configs/zynq_z_turn_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
CONFIG_ARCH_ZYNQ=y
CONFIG_SYS_TEXT_BASE=0x400
CONFIG_SPL_STACK_R_ADDR=0x20
-CONFIG_DEFAULT_DEVICE_TREE="zynq-zturn-myir"
+CONFIG_DEFAULT_DEVICE_TREE="zynq-zturn"
CONFIG_DEBUG_UART=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv3 1/2] ARM: dts: zynq: Update dts for Z-turn board
Delete devices implemented in PL, stylistic changes.
Signed-off-by: Anton Gerasimov
---
arch/arm/dts/zynq-zturn-myir.dts | 61
1 file changed, 12 insertions(+), 49 deletions(-)
diff --git a/arch/arm/dts/zynq-zturn-myir.dts b/arch/arm/dts/zynq-zturn-myir.dts
index a5ecfcc1d7..8aa384b59b 100644
--- a/arch/arm/dts/zynq-zturn-myir.dts
+++ b/arch/arm/dts/zynq-zturn-myir.dts
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) 2015 Andrea Merello
* Copyright (C) 2017 Alexander Graf
@@ -6,31 +7,23 @@
* Copyright (C) 2011 - 2014 Xilinx
* Copyright (C) 2012 National Instruments Corp.
*
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
+
/dts-v1/;
/include/ "zynq-7000.dtsi"
/ {
model = "Zynq Z-Turn MYIR Board";
- compatible = "xlnx,zynq-7000";
+ compatible = "myir,zynq-zturn", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
serial0 = &uart1;
serial1 = &uart0;
- spi0 = &qspi;
mmc0 = &sdhci0;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
@@ -41,52 +34,23 @@
gpio-leds {
compatible = "gpio-leds";
- led_r {
- label = "led_r";
- gpios = <&gpio0 0x72 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- led_g {
- label = "led_g";
- gpios = <&gpio0 0x73 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- led_b {
- label = "led_b";
- gpios = <&gpio0 0x74 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- usr_led1 {
- label = "usr_led1";
+ usr-led1 {
+ label = "usr-led1";
gpios = <&gpio0 0x0 0x1>;
default-state = "off";
- linux,default-trigger = "none";
};
- usr_led2 {
- label = "usr_led2";
+ usr-led2 {
+ label = "usr-led2";
gpios = <&gpio0 0x9 0x1>;
default-state = "off";
- linux,default-trigger = "none";
};
};
- gpio-beep {
- compatible = "gpio-beeper";
- label = "pl-beep";
- gpios = <&gpio0 0x75 0x0>;
- };
-
gpio-keys {
compatible = "gpio-keys";
- #address-cells = <0x1>;
- #size-cells = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
autorepeat;
K1 {
label = "K1";
@@ -100,7 +64,6 @@
&clkc {
ps-clk-frequency = <>;
- fclk-enable = <0xf>;
};
&qspi {
@@ -152,8 +115,8 @@
reg = <0x49>;
};
- adxl345@53 {
- compatible = "adi,adxl34x", "adxl34x";
+ accelerometer@53 {
+ compatible = "adi,adxl345", "adxl345", "adi,adxl34x", "adxl34x";
reg = <0x53>;
interrupt-parent = <&intc>;
interrupts = <0x0 0x1e 0x4>;
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv3 0/2] Changes to Z-turn dtd
Same as v2, but restored mmc0 alias. spi0 is deleted to avoid confusion
with spi0 from zynq-7000.dtsi.
Anton Gerasimov (2):
ARM: dts: zynq: Update dts for Z-turn board
ARM: dts: zynq: Rename dts for Z-turn board
arch/arm/dts/Makefile | 2 +-
.../dts/{zynq-zturn-myir.dts => zynq-zturn.dts}| 61 +-
configs/zynq_z_turn_defconfig | 2 +-
3 files changed, 14 insertions(+), 51 deletions(-)
rename arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} (55%)
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/2] ARM: dts: zynq: Update dts for Z-turn board
Hi Alex, - spi0 = &qspi; - mmc0 = &sdhci0; Why? ;) Sorry if you already explained it, but I don't quite grasp why we need to remove aliases. Sorry, I've missed that. The original reason was that qspi was missing from linux's zynq-7000.dtsi, but we'll probably just need to update it there, qspi is quite important for z-turn. I just see one potential point of confusion in that spi0 overrides actual spi0 (spi0@e0006000) in zynq-7000.dtsi. While it is not used on Z-turn by default, it can possibly be routed to one of the pins on an external connector. It can still be addressed by the full name of course. Thanks, Anton ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 2/2] ARM: dts: zynq: Rename dts for Z-turn board
Makes naming in line with other Zynq boards.
Signed-off-by: Anton Gerasimov
---
arch/arm/dts/Makefile| 2 +-
arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} | 0
configs/zynq_z_turn_defconfig| 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} (100%)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 20a4c37d48..83aa2f4df4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -143,7 +143,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
zynq-zed.dtb \
- zynq-zturn-myir.dtb \
+ zynq-zturn.dtb \
zynq-zybo.dtb
dtb-$(CONFIG_ARCH_ZYNQMP) += \
zynqmp-ep108.dtb\
diff --git a/arch/arm/dts/zynq-zturn-myir.dts b/arch/arm/dts/zynq-zturn.dts
similarity index 100%
rename from arch/arm/dts/zynq-zturn-myir.dts
rename to arch/arm/dts/zynq-zturn.dts
diff --git a/configs/zynq_z_turn_defconfig b/configs/zynq_z_turn_defconfig
index 7a51b85ac8..1270e30cab 100644
--- a/configs/zynq_z_turn_defconfig
+++ b/configs/zynq_z_turn_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
CONFIG_ARCH_ZYNQ=y
CONFIG_SYS_TEXT_BASE=0x400
CONFIG_SPL_STACK_R_ADDR=0x20
-CONFIG_DEFAULT_DEVICE_TREE="zynq-zturn-myir"
+CONFIG_DEFAULT_DEVICE_TREE="zynq-zturn"
CONFIG_DEBUG_UART=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 1/2] ARM: dts: zynq: Update dts for Z-turn board
Delete devices implemented in PL, stylistic changes.
Signed-off-by: Anton Gerasimov
---
arch/arm/dts/zynq-zturn-myir.dts | 62
1 file changed, 12 insertions(+), 50 deletions(-)
diff --git a/arch/arm/dts/zynq-zturn-myir.dts b/arch/arm/dts/zynq-zturn-myir.dts
index a5ecfcc1d7..a9be2c8374 100644
--- a/arch/arm/dts/zynq-zturn-myir.dts
+++ b/arch/arm/dts/zynq-zturn-myir.dts
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) 2015 Andrea Merello
* Copyright (C) 2017 Alexander Graf
@@ -6,31 +7,22 @@
* Copyright (C) 2011 - 2014 Xilinx
* Copyright (C) 2012 National Instruments Corp.
*
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
+
/dts-v1/;
/include/ "zynq-7000.dtsi"
/ {
model = "Zynq Z-Turn MYIR Board";
- compatible = "xlnx,zynq-7000";
+ compatible = "myir,zynq-zturn", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
serial0 = &uart1;
serial1 = &uart0;
- spi0 = &qspi;
- mmc0 = &sdhci0;
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x0 0x4000>;
};
@@ -41,52 +33,23 @@
gpio-leds {
compatible = "gpio-leds";
- led_r {
- label = "led_r";
- gpios = <&gpio0 0x72 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- led_g {
- label = "led_g";
- gpios = <&gpio0 0x73 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- led_b {
- label = "led_b";
- gpios = <&gpio0 0x74 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- usr_led1 {
- label = "usr_led1";
+ usr-led1 {
+ label = "usr-led1";
gpios = <&gpio0 0x0 0x1>;
default-state = "off";
- linux,default-trigger = "none";
};
- usr_led2 {
- label = "usr_led2";
+ usr-led2 {
+ label = "usr-led2";
gpios = <&gpio0 0x9 0x1>;
default-state = "off";
- linux,default-trigger = "none";
};
};
- gpio-beep {
- compatible = "gpio-beeper";
- label = "pl-beep";
- gpios = <&gpio0 0x75 0x0>;
- };
-
gpio-keys {
compatible = "gpio-keys";
- #address-cells = <0x1>;
- #size-cells = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
autorepeat;
K1 {
label = "K1";
@@ -100,7 +63,6 @@
&clkc {
ps-clk-frequency = <>;
- fclk-enable = <0xf>;
};
&qspi {
@@ -152,8 +114,8 @@
reg = <0x49>;
};
- adxl345@53 {
- compatible = "adi,adxl34x", "adxl34x";
+ accelerometer@53 {
+ compatible = "adi,adxl345", "adxl345", "adi,adxl34x", "adxl34x";
reg = <0x53>;
interrupt-parent = <&intc>;
interrupts = <0x0 0x1e 0x4>;
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 0/2] Changes to Z-turn dts
Updated patch to dts for Z-turn board. Thanks Alex and Michal for
corections. Tested with both u-boot and linux kernel, works fine.
Once it gets accepted to U-boot I'll send the final version to
Linux devicetree mailing list.
Anton Gerasimov (2):
ARM: dts: zynq: Update dts for Z-turn board
ARM: dts: zynq: Rename dts for Z-turn board
arch/arm/dts/Makefile | 2 +-
.../dts/{zynq-zturn-myir.dts => zynq-zturn.dts}| 62 +-
configs/zynq_z_turn_defconfig | 2 +-
3 files changed, 14 insertions(+), 52 deletions(-)
rename arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} (54%)
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: dts: zynq: Update dts for Z-turn board
Hi Alexander,
device_type = "memory";
reg = <0x0 0x4000>;
};
chosen {
- stdout-path = "serial0:115200n8";
Nack. By default graphical output is quite unusable on this board, so we
want to output to serial.
If your Linux submitted device tree doesn't contain this part, please
fix it there.
+ bootargs = "console=ttyPS0,115200 earlyprintk root=/dev/mmcblk0p2
rootwait";
This is even worse. Please don't prepopulate any bootargs, otherwise
people may end up assuming that they're actually getting used.
The older one is much cleaner I agree, thank you. I'll just need to test
with both u-boot and linux.
};
gpio-leds {
compatible = "gpio-leds";
- led_r {
- label = "led_r";
- gpios = <&gpio0 0x72 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- led_g {
- label = "led_g";
- gpios = <&gpio0 0x73 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
-
- led_b {
- label = "led_b";
- gpios = <&gpio0 0x74 0x1>;
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
Why remove them? They're hard wired on the board, no?
No this RGB LED is connected to PL, that's for sure.
ps-clk-frequency = <>;
- fclk-enable = <0xf>;
Why?
IIRC on my Z-Turn, I had to take a PL clock back into the PS as AXI
reference clock. See "Connect clocks" here:
https://wiki.hackerspace.pl/projects:zturn-hackers:helloworld
So we need to have the PL clock enabled, no? Or is that only needed for
PL AXI peripherals?
As far as I understand M_AXI_GPn connects AXI slaves implemented on PL
to AXI and S_AXI_HPn provides access for AXI slaves in PS to PL slaves.
So both involve PL and can be disconnected if PL is not clocked.
};
&qspi {
@@ -152,8 +114,8 @@
reg = <0x49>;
};
- adxl345@53 {
- compatible = "adi,adxl34x", "adxl34x";
+ accelerometer@53 {
+ compatible = "adi,adxl345", "adxl345";
You can't just remove compatibles. Device trees are supposed to be
compatible with whatever used them before someone thought they want to
prettify them, so in this case you'd have to add the concrete names in
the list before the abstract ones:
compatible = "adi,adxl345", "adxl345", "adi,adxl34x", "adxl34x";
Yes sorry, I didn't realize that Linux kernel had both.
Best,
Anton
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Move Cache-As-RAM memory from area mapped to ROM in QEMU
ROM has been made read-only in qemu recently (namely commit 208fa0e43645edd0b0d8f838857dfc79daff40a8), so this patch restores compatibility between u-boot and qemu. Signed-off-by: Anton Gerasimov --- arch/x86/cpu/qemu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig index 6808c9a6b9..f4b9922a34 100644 --- a/arch/x86/cpu/qemu/Kconfig +++ b/arch/x86/cpu/qemu/Kconfig @@ -11,7 +11,7 @@ if QEMU config SYS_CAR_ADDR hex - default 0xd + default 0x1 config SYS_CAR_SIZE hex -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Move Cache-As-RAM memory from area mapped to ROM in QEMU
Thank you Heinrich, I can confirm that current u-boot master works without reverting 55751ab1. I had problems with u-boot v2017.11-rc2 apparently. Best regards, Anton Gerasimov On 11/11/2017 12:08 PM, Heinrich Schuchardt wrote: > On 11/10/2017 06:51 PM, Anton Gerasimov wrote: >> ROM has been made read-only in qemu recently (namely commit >> 208fa0e43645edd0b0d8f838857dfc79daff40a8), so this patch restores >> compatibility between u-boot and qemu. It is still broken for me >> unless I set CONFIG_SMP=n and disable lapic (i.e. revert patch >> 55751ab1e5a5cfa0962d604593a7e6f33ff6 in u-boot), but these are >> separate issues > > I could not reproduce that reverting 55751ab1 is necessary. > Your patch and CONFIG_SMP=n was suffcient to start U-Boot with > qemu-system-x86_64 version 2.10.1(Debian 1:2.10.0+dfsg-2) > > Tested-by: Heinrich Schuchardt > >> >> Signed-off-by: Anton Gerasimov >> --- >> arch/x86/cpu/qemu/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig >> index 6808c9a6b9..f4b9922a34 100644 >> --- a/arch/x86/cpu/qemu/Kconfig >> +++ b/arch/x86/cpu/qemu/Kconfig >> @@ -11,7 +11,7 @@ if QEMU >> config SYS_CAR_ADDR >> hex >> - default 0xd >> + default 0x1 >> config SYS_CAR_SIZE >> hex >> > -- Anton Gerasimov, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk Pöschl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Move Cache-As-RAM memory from area mapped to ROM in QEMU
ROM has been made read-only in qemu recently (namely commit 208fa0e43645edd0b0d8f838857dfc79daff40a8), so this patch restores compatibility between u-boot and qemu. It is still broken for me unless I set CONFIG_SMP=n and disable lapic (i.e. revert patch 55751ab1e5a5cfa0962d604593a7e6f33ff6 in u-boot), but these are separate issues Signed-off-by: Anton Gerasimov --- arch/x86/cpu/qemu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig index 6808c9a6b9..f4b9922a34 100644 --- a/arch/x86/cpu/qemu/Kconfig +++ b/arch/x86/cpu/qemu/Kconfig @@ -11,7 +11,7 @@ if QEMU config SYS_CAR_ADDR hex - default 0xd + default 0x1 config SYS_CAR_SIZE hex -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of latest qemux86-64
Hooray, changing SYS_CAR_ADDR to 0x1 in arch/x86/cpu/qemu/Kconfig
does the trick. Bin, what do you think about it?
Best regards,
Anton Gerasimov
On 11/10/2017 06:25 PM, Anton Gerasimov wrote:
> Yes, apparently 0xdfffc is in ROM area for QEMU (0xc -- 0xe,
> defined in include/hw/loader.h). The next thing to figure out is why
> u-boot uses it as a stack area.
>
> Best regards,
> Anton Gerasimov
>
> On 11/10/2017 06:04 PM, Anton Gerasimov wrote:
>> New guess:
>>
>> in the most safe configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
>> with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
>> fails on the first 'ret' instruction. GDB shows that memory at $esp
>> (0xdfffc at the entrance to board_init_f_mem) and everything around it
>> is zero despite 'call' and 'push' instructions executed. If you go one
>> commit before the breaking one it works fine, stuff gets put onto stack.
>> Could it that be that stack itself is in this 'readonly' area?
>>
>> Thanks,
>> Anton Gerasimov
>>
>> On 11/09/2017 02:58 AM, Bin Meng wrote:
>>> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
>>> wrote:
>>>> Adding Igor Mammedov to the loop.
>>>>
>>> Really add Igor Mammedov.
>>>
>>> Igor, can you help look at this?
>>>
>>>> On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
>>>>> To whoever might be interested: I've bisected qemu and the breaking
>>>>> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
>>>>> readonly when machine has PCI enabled). It's just three lines added,
>>>>> I'll paste the whole patch here. Not quite sure what can we do here
>>>>> though.
>>>>>
>>>>>
>>>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>>> index 22e16031b0..59435390ba 100644
>>>>> --- a/hw/i386/pc.c
>>>>> +++ b/hw/i386/pc.c
>>>>> @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>>>option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>>> memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>>>> &error_fatal);
>>>>> +if (pcmc->pci_enabled) {
>>>>> +memory_region_set_readonly(option_rom_mr, true);
>>>>> +}
>>>>>memory_region_add_subregion_overlap(rom_memory,
>>>>>PC_ROM_MIN_VGA,
>>>>>option_rom_mr,
>>>>>
>>>>>
>>> Regards,
>>> Bin
--
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of latest qemux86-64
Yes, apparently 0xdfffc is in ROM area for QEMU (0xc -- 0xe,
defined in include/hw/loader.h). The next thing to figure out is why
u-boot uses it as a stack area.
Best regards,
Anton Gerasimov
On 11/10/2017 06:04 PM, Anton Gerasimov wrote:
> New guess:
>
> in the most safe configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
> with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
> fails on the first 'ret' instruction. GDB shows that memory at $esp
> (0xdfffc at the entrance to board_init_f_mem) and everything around it
> is zero despite 'call' and 'push' instructions executed. If you go one
> commit before the breaking one it works fine, stuff gets put onto stack.
> Could it that be that stack itself is in this 'readonly' area?
>
> Thanks,
> Anton Gerasimov
>
> On 11/09/2017 02:58 AM, Bin Meng wrote:
>> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
>> wrote:
>>> Adding Igor Mammedov to the loop.
>>>
>> Really add Igor Mammedov.
>>
>> Igor, can you help look at this?
>>
>>> On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
>>>> To whoever might be interested: I've bisected qemu and the breaking
>>>> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
>>>> readonly when machine has PCI enabled). It's just three lines added,
>>>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>>>
>>>>
>>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>> index 22e16031b0..59435390ba 100644
>>>> --- a/hw/i386/pc.c
>>>> +++ b/hw/i386/pc.c
>>>> @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>>option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>>memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>>> &error_fatal);
>>>> +if (pcmc->pci_enabled) {
>>>> +memory_region_set_readonly(option_rom_mr, true);
>>>> +}
>>>>memory_region_add_subregion_overlap(rom_memory,
>>>>PC_ROM_MIN_VGA,
>>>>option_rom_mr,
>>>>
>>>>
>> Regards,
>> Bin
>
--
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of latest qemux86-64
New guess:
in the most safe configuration of u-boot (CONFIG_SMP=n, lacpi disabled)
with Igor's patch applied `qemu-system-i386 -bios /path/to/uboot.rom`
fails on the first 'ret' instruction. GDB shows that memory at $esp
(0xdfffc at the entrance to board_init_f_mem) and everything around it
is zero despite 'call' and 'push' instructions executed. If you go one
commit before the breaking one it works fine, stuff gets put onto stack.
Could it that be that stack itself is in this 'readonly' area?
Thanks,
Anton Gerasimov
On 11/09/2017 02:58 AM, Bin Meng wrote:
> On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
> wrote:
>> Adding Igor Mammedov to the loop.
>>
> Really add Igor Mammedov.
>
> Igor, can you help look at this?
>
>> On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
>>> To whoever might be interested: I've bisected qemu and the breaking
>>> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
>>> readonly when machine has PCI enabled). It's just three lines added,
>>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>>
>>>
>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>> index 22e16031b0..59435390ba 100644
>>> --- a/hw/i386/pc.c
>>> +++ b/hw/i386/pc.c
>>> @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>>option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>>memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>> &error_fatal);
>>> +if (pcmc->pci_enabled) {
>>> +memory_region_set_readonly(option_rom_mr, true);
>>> +}
>>>memory_region_add_subregion_overlap(rom_memory,
>>>PC_ROM_MIN_VGA,
>>>option_rom_mr,
>>>
>>>
> Regards,
> Bin
--
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of latest qemux86-64
Adding Igor Mammedov to the loop.
On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
> To whoever might be interested: I've bisected qemu and the breaking
> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
> readonly when machine has PCI enabled). It's just three lines added,
> I'll paste the whole patch here. Not quite sure what can we do here though.
>
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 22e16031b0..59435390ba 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
> option_rom_mr = g_malloc(sizeof(*option_rom_mr));
> memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
> &error_fatal);
> + if (pcmc->pci_enabled) {
> + memory_region_set_readonly(option_rom_mr, true);
> + }
> memory_region_add_subregion_overlap(rom_memory,
> PC_ROM_MIN_VGA,
> option_rom_mr,
>
>
> Thanks,
> Anton
>
>
> On 11/06/2017 02:55 AM, Bin Meng wrote:
>> +QEMU dev list
>>
>> On Fri, Nov 3, 2017 at 10:07 PM, Anton Gerasimov
>> wrote:
>>> Hi all,
>>>
>>> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
>>> run into a "trying to execute code outside of RAM or ROM at x"
>>> issue. It happens both when I build and use u-boot as a bios and as EFI
>>> payload, just the addresses in the error message are different. On qemu
>>> v2.5.0 at least EFI option works fine.
>>>
>>> I understand that it can be (and probably is) a QEMU issue, but maybe
>>> someone on the list already encountered it and knows a workaround or has
>>> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>>>
>> Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
>> 2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
>> 2.10.1.
>>
>> I built U-Boot as follows:
>>
>> $ make qemu-x86_defconfig
>> $ make
>>
>> Does anyone have any hints?
>>
>> Regards,
>> Bin
>
--
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of latest qemux86-64
To whoever might be interested: I've bisected qemu and the breaking
commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
readonly when machine has PCI enabled). It's just three lines added,
I'll paste the whole patch here. Not quite sure what can we do here though.
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 22e16031b0..59435390ba 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
option_rom_mr = g_malloc(sizeof(*option_rom_mr));
memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
&error_fatal);
+ if (pcmc->pci_enabled) {
+ memory_region_set_readonly(option_rom_mr, true);
+ }
memory_region_add_subregion_overlap(rom_memory,
PC_ROM_MIN_VGA,
option_rom_mr,
Thanks,
Anton
On 11/06/2017 02:55 AM, Bin Meng wrote:
> +QEMU dev list
>
> On Fri, Nov 3, 2017 at 10:07 PM, Anton Gerasimov
> wrote:
>> Hi all,
>>
>> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
>> run into a "trying to execute code outside of RAM or ROM at x"
>> issue. It happens both when I build and use u-boot as a bios and as EFI
>> payload, just the addresses in the error message are different. On qemu
>> v2.5.0 at least EFI option works fine.
>>
>> I understand that it can be (and probably is) a QEMU issue, but maybe
>> someone on the list already encountered it and knows a workaround or has
>> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>>
> Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
> 2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
> 2.10.1.
>
> I built U-Boot as follows:
>
> $ make qemu-x86_defconfig
> $ make
>
> Does anyone have any hints?
>
> Regards,
> Bin
--
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of latest qemux86-64
Some more details: EFI on QEMU v2.9.0 works as well, it's v2.10.0 where some incompatibilities are introduced. The last stable tag of u-boot that works (under qemu <= v2.9.0) as BIOS for me is v2015.07. Starting from v2015.10 when I run qemu-system-x86_64 --bios u-boot.rom -nographic I get the following dump: Invalid Opcode (Undefined Opcode) EIP: 0010:[<07f56583>] EFLAGS: 0006 Original EIP :[] EAX: 00aa EBX: 07fab61c ECX: 006a EDX: 006b ESI: EDI: 0003 EBP: ESP: 07d52620 DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018 CR0: 0033 CR2: CR3: CR4: DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Stack: 0x07d52660 : 0x07f58460 0x07d5265c : 0x07f77947 0x07d52658 : 0x 0x07d52654 : 0x 0x07d52650 : 0x0001 0x07d5264c : 0x07fab61c 0x07d52648 : 0x 0x07d52644 : 0x07fa319c 0x07d52640 : 0x 0x07d5263c : 0x07f8ba2f 0x07d52638 : 0x07d52780 0x07d52634 : 0x07fab61c 0x07d52630 : 0x07fcf200 0x07d5262c : 0x07f77cb2 0x07d52628 : 0x0202 0x07d52624 : 0x0010 --->0x07d52620 : 0x07f77bdc 0x07d5261c : 0x0006 0x07d52618 : 0x0010 0x07d52614 : 0x07f56583 ### ERROR ### Please RESET the board ### Debugging with gdb shows that it happens after transferring control to RAM (board_f.c:1027 in v2015.10), but couldn't get more details so far, so any help is appreciated. Best regards, Anton Gerasimov On 11/03/2017 03:07 PM, Anton Gerasimov wrote: > Hi all, > > I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and > run into a "trying to execute code outside of RAM or ROM at x" > issue. It happens both when I build and use u-boot as a bios and as EFI > payload, just the addresses in the error message are different. On qemu > v2.5.0 at least EFI option works fine. > > I understand that it can be (and probably is) a QEMU issue, but maybe > someone on the list already encountered it and knows a workaround or has > successfully used u-boot with QEMU >=2.10.0 and can share their experience. > > Thanks in advance. > > Best regards, > Anton Gerasimov > > -- Anton Gerasimov, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk Pöschl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Support of latest qemux86-64
Hi all, I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and run into a "trying to execute code outside of RAM or ROM at x" issue. It happens both when I build and use u-boot as a bios and as EFI payload, just the addresses in the error message are different. On qemu v2.5.0 at least EFI option works fine. I understand that it can be (and probably is) a QEMU issue, but maybe someone on the list already encountered it and knows a workaround or has successfully used u-boot with QEMU >=2.10.0 and can share their experience. Thanks in advance. Best regards, Anton Gerasimov ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
