[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8917c9a1-09e9-0a39-5732-da7f555ae9ad@xilinx.com>
Date: Thu, 21 Jan 2021 11:23:46 +0100
From: Michal Simek <michal.simek@...inx.com>
To: Michael Walle <michael@...le.cc>,
Michal Simek <michal.simek@...inx.com>
CC: <devicetree@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
"Arnd Bergmann" <arnd@...db.de>, Olof Johansson <olof@...om.net>,
<soc@...nel.org>
Subject: Re: [PATCH 0/3] add Ebang EBAZ4205 support
Hi,
On 1/21/21 11:13 AM, Michael Walle wrote:
> Hi,
>
> Am 2021-01-21 10:57, schrieb Michal Simek:
>> Hi,
>>
>> On 1/21/21 10:35 AM, Michael Walle wrote:
>>> Hi Michal,
>>>
>>> Am 2021-01-21 10:25, schrieb Michal Simek:
>>>> On 1/20/21 8:40 PM, Michael Walle wrote:
>>>>> Add support for the Ebang EBAZ4205 board. This board was once used
>>>>> as a
>>>>> control board for a bitcoin mining device. Nowawdays it is sold as a
>>>>> cheap
>>>>> Zynq-7000 eval board.
>>>>>
>>>>> Michael Walle (3):
>>>>> dt-bindings: add ebang vendor prefix
>>>>> dt-bindings: arm: add Ebang EBAZ4205 board
>>>>> ARM: dts: add Ebang EBAZ4205 device tree
>>>>>
>>>>> .../devicetree/bindings/arm/xilinx.yaml | 1 +
>>>>> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
>>>>> arch/arm/boot/dts/Makefile | 1 +
>>>>> arch/arm/boot/dts/zynq-ebaz4205.dts | 109
>>>>> ++++++++++++++++++
>>>>> 4 files changed, 113 insertions(+)
>>>>> create mode 100644 arch/arm/boot/dts/zynq-ebaz4205.dts
>>>>>
>>>>
>>>> any link with schematics?
>>>
>>> https://github.com/xjtuecho/EBAZ4205, looks like these are
>>> reverse engineered (from a layout file?) though.
>>
>> Interesting but at least something.
>>
>>>
>>>> I will let dt guys to comment 1/3 but series look good to me.
>>>> The board doesn't look interesting from description point of view
>>>> that's
>>>> why all the time thinking if makes sense to add it to kernel.
>>>
>>> What do you want to tell me? That for the time being, it didn't
>>> appear to you to add the board yourself - or do you thing it
>>> doesn't make sense at all. If its the latter, what would be
>>> actual reason to have a board in mainline?
>>
>> I have bad experience with for example Avnet boards which people add and
>> none is really updating them and they are in the same state for years.
>
> Wouldn't it be better then to pull the plug at some time and remove these
> boards.
>
> TBH I was a bit disappointed by your statement. It sounded like "nah
> this board isn't worth it". Esp. because it is just one (small) file.
> But more below.
>
>> Long time ago we agreed that doesn't make sense to describe PL in
>> upstream projects and we only describe PS part. It means you likely miss
>> several things which are useful and the reason for using these SoCs is
>> PL.
>>
>> As you likely know Xilinx has Versal device and I didn't push any device
>> tree to any upstream project and thinking not to add any description for
>> boards and stay in sort of space that "virtual" description for SoC
>> should be enough. Maybe just versal.dtsi and one kitchen sink DT should
>> be added but not description for all boards.
>>
>> The same is if make sense to push all DTs for all standard xilinx zynqmp
>> evaluation boards. If there is something interesting/new I thought it
>> makes sense to add it as pattern to follow. But for boards which looks
>> very similar from PS point of view I don't think there is real value to
>> add and invest time for maintaining.
>>
>> Back to your case. Board is cheap which is not all the time case for any
>> xilinx board but you have only uart, sd and partially described ethernet
>> which doesn't work without PL. Is it worth to have this described?
>
> I got your point. But it is at least a jump start for the users if that
> board boots out of the box. And yes, its unfortunate, that ethernet
> just works if the PL is configured. This is already done by the
> bootloader, because there I do have the same problem.
Zynq/ZynqMP boards can use U-Boot SPL. "Advantage" of this solution
especially for Zynq is that in u-boot there is open a way for adding
ps7_init file which is determined by device tree name.
I think it would make sense to add these DTs and also ps7_init to U-Boot
project and wire it up with zynq_virt platform and then you can boot
Linux with using U-Boot's DT pointed by $fdtcontroladdr.
Then you will get support from scratch to be able to boot.
Thanks,
Michal
Powered by blists - more mailing lists