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
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
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-
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,
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
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
---
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 memor
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
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
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
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 del
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, Ant
.
Best regargs,
Anton Gerasimov
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
#x27;
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
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(+)
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
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
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
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(+)
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
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
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
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
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), 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
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
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
ng 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
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&
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 qe
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 b
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.
B
32 matches
Mail list logo
