On 5/29/19 3:34 PM, Michal Simek wrote:
On 29. 05. 19 14:31, Hannes Schmelzer wrote:
On 5/27/19 8:35 AM, Michal Simek wrote:
On 10. 05. 19 7:52, Hannes Schmelzer wrote:
This commit adds the first of a few more Xilinx ZYNQ based SoM boards.
The SoM is based on Xilinx Zynq 7000 SoC.
Mainly vxWorks 6.9.4.x is running on the board,
doing some PLC stuff on various carrier boards.
Signed-off-by: Hannes Schmelzer <hannes.schmel...@br-automation.com>
arch/arm/dts/Makefile | 2 +
arch/arm/dts/zynq-brsmarc2-common.dtsi | 168 +++++++++++++++++
arch/arm/dts/zynq-brsmarc2-vxworks.dtsi | 123 +++++++++++++
arch/arm/dts/zynq-brsmarc2.dts | 15 ++
arch/arm/dts/zynq-brsmarc2_r512.dts | 15 ++
board/BuR/zynq/.gitignore | 1 +
board/BuR/zynq/MAINTAINERS | 6 +
board/BuR/zynq/Makefile | 16 ++
board/BuR/zynq/brsmarc2/board.c | 63 +++++++
board/BuR/zynq/brsmarc2/ps7_init_gpl.c | 276
++++++++++++++++++++++++++++
board/BuR/zynq/brsmarc2_r512/board.c | 2 +
board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c | 276
++++++++++++++++++++++++++++
If these locations are there just because of that ps7_init_gpl wiring
because of DT dependency then you should look at XILINX_PS_INIT_FILE
option.
Good point.
I will have a look at this.
But on first view into the Makefile i think it will not work.
This option is catched within "board/xilinx/zynq/Makefile" but this
Makefile doesn't run for me or my boards.
you should be able to include that Makefile in yours.
I looked into again and came to the result that this Makefile doesn't
fit to my needs (producing some output into 'board/xilinx/zynq/....',
compiling thing like "cmd", "bootimg" into ...
diff --git a/arch/arm/dts/zynq-brsmarc2-vxworks.dtsi
b/arch/arm/dts/zynq-brsmarc2-vxworks.dtsi
new file mode 100644
index 0000000..a1251c3
--- /dev/null
+++ b/arch/arm/dts/zynq-brsmarc2-vxworks.dtsi
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * primary OS (vxWorks 6.9.4.x) specific parts for B&R BRSMARC2 boards
+ *
+ * Copyright (C) 2019 B&R Industrial Automation GmbH
+ */
+
+#include "zynq-brsmarc2-common.dtsi"
+
+/ {
+ fset: factory-settings {
+ compatible = "bur,fsetv1";
+ bl-version = " ";
+ order-no = " ";
+ cpu-order-no = " ";
+ hw-revision = " ";
+ serial-no = <0>;
+ device-id = <0x0>;
+ parent-id = <0x0>;
+ hw-variant = <0x0>;
+ hw-platform = <0x0>;
+ fram-offset = <0x0>;
+ fram-size = <0x0>;
+ cache-disable = <0x0>;
+ cpu-clock = <0x0>;
+ };
+
+ aliases {
+ fset = &fset;
+ };
+
+ board {
+ status = "okay";
+ compatible = "bur,brsmarc2-som";
+ usb0mux-gpios = <&gpio0 68 GPIO_ACTIVE_HIGH>;
+ usb1mux-gpios = <&gpio0 69 GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+ };
+
+ fpga: fpga@40000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
I think that all these PL nodes should go away. We have been discussing
this long time ago that we won't push any PL description to mainline
because it can change.
I would recommend you to switch this to DT overlay which your boot
script will apply for you.
Also there is no point to add IPs with status disabled to board file.
the disable/okay can be changed by some factory-script (u-boot-script),
which runs quite before booting the vxWorks kernel. Here we enable/
disable features.
DT overlay is too late for me in the actual state of my product,
i have running running systems here and will not do such fundamental
change.
Can we make the establishment taking my -vxworks.dtsi away from review?
Adding things to mainline is out of any state of product. It shouldn't
be a problem to add stuff which are reviewed and not add things which
are problematic.
I have not a problem with your vxworks binding but I have issue with
describing something what shouldn't be here.
I cannot see here problematic stuff, so it should be able to be merged.
Problematic would be things that breaks build or violating dts spec.
diff --git a/board/BuR/zynq/brsmarc2_r512/board.c
b/board/BuR/zynq/brsmarc2_r512/board.c
new file mode 100644
index 0000000..a70c2aa
--- /dev/null
+++ b/board/BuR/zynq/brsmarc2_r512/board.c
@@ -0,0 +1,2 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include "../brsmarc2/board.c"
Any reason for this? You can simply move it to zynq folder and have this
common for both boards variants.
Yes, because i want to use standard build procedure while don't having
duplicate code.
Just replace this
+obj-y += $(hw-platform-y)/board.o
by
+obj-y += board.o
and you are done.
Yes, this would be true if there are only these two zynq boards,
sharing the same board code. For current point of view this is true.
But here in my tree there are living two more, a third is on my list
to be implemented.
So for having good readability and good traceability i would prefer
this way (for the ps7 files also).
If i have a question regarding one of my zynq boards i simply walk into
board/BuR/zynq/<that-board> and see every related stuff.
I think that this file should be designed differently.
You should #include <configs/zynq-common.h> first and then change
whatever you don't like.
There are a lot of things which are just c&p from this file and it will
be hard to fix all zynq boards by changing one file.
Yes there are much thing c/p from a verly early stage when zynq was
introduced into u-boot. I still think that my way fits best to my needs,
zynq-common as very much stuff which i don't need at all. It will make
readability of my board worse.
Of course general fixes will not be applied to my boards, this maybe good
or not. Often things are changed by somebody, but anybody can have
all corner cases within her/him viewing angle. With this way i think i have
most stable conditions for my boards and can take thinks from common
if think they are useful or maybe taking them not because i have trouble
with it.
I understand your opinion that it is the most easier way how to maintain
it. On the other hand we need to have setup where with minimal effort we
can update all zynq boards.
Adding board to mainline is also bringing responsibility to test that
boards and keep them alive. There should be some changes in connection
to SPL, variable setup to move to more zynq generic board which is
something I plan to do. Xilinx Versal has done this step, ZynqMP is on
the way and then Zynq should be converted too.
I'm of course aware of this responsibility and i think being on a
good way to fulfill the same. I have here around 10 boards on
5 different architectures running. Keeping all them up to date,
building, testing, report or fix things which get broken over time.
But using someones common stuff at any price doesn't make sense.
Maybe some day a zynq-common.h with absolute bare minimum,
then it can be used.
Thanks,
Michal
thanks again for your help,
cheers Hannes
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
