Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.62.198 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.62.198; helo=xsj-pvapexch02.xlnx.xilinx.com;
Envelope-to: michal.simek@xilinx.com,
 soc@kernel.org,
 olof@lixom.net,
 arnd@arndb.de,
 robh+dt@kernel.org,
 linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org,
 devicetree@vger.kernel.org,
 michael@walle.cc
Subject: Re: [PATCH 0/3] add Ebang EBAZ4205 support
To:     Michael Walle <michael@walle.cc>,
        Michal Simek <michal.simek@xilinx.com>
CC:     <devicetree@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
        "Arnd Bergmann" <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
        <soc@kernel.org>
References: <20210120194033.26970-1-michael@walle.cc>
 <fff420d1-fc9a-23ce-0d07-58a3c6f10c4d@xilinx.com>
 <aa96fcaa362181d4b6fef9f1de0aa914@walle.cc>
 <0a1c6ebf-1d5b-4f06-56db-f04e87d2ae9a@xilinx.com>
 <bd86194a13882ce472764d0c91029e33@walle.cc>
From:   Michal Simek <michal.simek@xilinx.com>
Message-ID: <8917c9a1-09e9-0a39-5732-da7f555ae9ad@xilinx.com>
Date:   Thu, 21 Jan 2021 11:23:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <bd86194a13882ce472764d0c91029e33@walle.cc>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2021 10:23:51.1640
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cbd60919-86c8-49f2-53b2-08d8bdf6a5af
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.62.198];Helo=[xsj-pvapexch02.xlnx.xilinx.com]
X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT007.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2400
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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