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
