[PATCH 0/3] add Ebang EBAZ4205 support

[Michal Simek]

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