[U-Boot] [PATCH v3] board/BuR/zynq/brsmarc2: initial commit
Hannes Schmelzer
hannes at schmelzer.or.at
Fri May 31 05:43:32 UTC 2019
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.schmelzer at 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 at 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
More information about the U-Boot
mailing list