[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

[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

[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

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

[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

[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

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

[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

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

[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

[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

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 wr

[U-Boot] Writes to FAT broken by bcm2835 sdhost driver

, 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

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 <tos...@gmail.com> --- arch/arm/dts/Makefile| 2 +- arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} | 0 configs/zynq_z_turn_defconfig| 2 +- 3 file

[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 <tos...@gmail.com> --- 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/ar

[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

Re: [U-Boot] [PATCHv2 1/2] ARM: dts: zynq: Update dts for Z-turn board

Hi Alex, - spi0 = - mmc0 = 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

[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 <tos...@gmail.com> --- arch/arm/dts/Makefile| 2 +- arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts} | 0 configs/zynq_z_turn_defconfig| 2 +- 3 file

[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 <tos...@gmail.com> --- 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/ar

[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

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

[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 <an...@advancedtelematic.com> --- arch/x86/cpu/qemu/Kconfig | 2 +- 1 file changed, 1 ins

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

[U-Boot] [PATCH] Move Cache-As-RAM memory from area mapped to ROM in QEMU

in u-boot), but these are separate issues Signed-off-by: Anton Gerasimov <an...@advancedtelematic.com> --- 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 ---

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 incl

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 conf

Re: [U-Boot] Support of latest qemux86-64

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

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 li

Re: [U-Boot] Support of latest qemux86-64

C_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 > <an...@advancedtelematic.com> wrote: >> Hi all, >> >> I'm trying to use u-boot (v2017.01) with qem

Re: [U-Boot] Support of latest qemux86-64

iated. 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 buil

[U-Boot] Support of latest qemux86-64

emu 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 r