вт, 18 лют. 2025 р. о 11:35 Quentin Schulz <quentin.sch...@cherry.de> пише: > > Hi Svyatoslav, > > On 2/18/25 8:12 AM, Svyatoslav Ryhel wrote: > > пн, 17 лют. 2025 р. о 18:51 Quentin Schulz <quentin.sch...@cherry.de> пише: > >> > >> Hi Svyatoslav, > >> > >> On 2/16/25 7:16 PM, Svyatoslav Ryhel wrote: > >>> The Acer Iconia A500 is a tablet computer designed, developed and > >>> marketed by Acer Inc. It is powered by 1 GHz Nvidia Tegra 2 processor > >>> and 1GB DDR2 RAM. The A500 is sold with 64 GB, although both 16 GB > >>> and 32 GB models are available. > >>> > >>> Signed-off-by: Svyatoslav Ryhel <clamo...@gmail.com> > >>> --- > >>> arch/arm/dts/Makefile | 1 + > >>> arch/arm/dts/tegra20-acer-a500-picasso.dts | 508 +++++++++++++++++++++ > >>> arch/arm/mach-tegra/tegra20/Kconfig | 5 + > >>> board/acer/picasso/Kconfig | 12 + > >>> board/acer/picasso/MAINTAINERS | 7 + > >>> board/acer/picasso/Makefile | 9 + > >>> board/acer/picasso/picasso.c | 57 +++ > >>> board/acer/picasso/picasso.env | 18 + > >>> configs/picasso_defconfig | 83 ++++ > >>> doc/board/acer/index.rst | 9 + > >>> doc/board/acer/picasso.rst | 125 +++++ > >>> doc/board/index.rst | 1 + > >>> include/configs/picasso.h | 23 + > >>> 13 files changed, 858 insertions(+) > >>> create mode 100644 arch/arm/dts/tegra20-acer-a500-picasso.dts > >>> create mode 100644 board/acer/picasso/Kconfig > >>> create mode 100644 board/acer/picasso/MAINTAINERS > >>> create mode 100644 board/acer/picasso/Makefile > >>> create mode 100644 board/acer/picasso/picasso.c > >>> create mode 100644 board/acer/picasso/picasso.env > >>> create mode 100644 configs/picasso_defconfig > >>> create mode 100644 doc/board/acer/index.rst > >>> create mode 100644 doc/board/acer/picasso.rst > >>> create mode 100644 include/configs/picasso.h > >>> > >>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > >>> index 0bf3697bdbe..acea0cc2ec1 100644 > >>> --- a/arch/arm/dts/Makefile > >>> +++ b/arch/arm/dts/Makefile > >>> @@ -84,6 +84,7 @@ dtb-$(CONFIG_ARCH_MESON) += \ > >>> meson-a1-ad401.dtb > >>> > >>> dtb-$(CONFIG_ARCH_TEGRA) += \ > >>> + tegra20-acer-a500-picasso.dtb \ > >>> tegra20-asus-sl101.dtb \ > >>> tegra20-asus-tf101.dtb \ > >>> tegra20-asus-tf101g.dtb \ > >>> diff --git a/arch/arm/dts/tegra20-acer-a500-picasso.dts > >>> b/arch/arm/dts/tegra20-acer-a500-picasso.dts > >>> new file mode 100644 > >>> index 00000000000..0c301483180 > >>> --- /dev/null > >>> +++ b/arch/arm/dts/tegra20-acer-a500-picasso.dts > >> > >> Small drive-by comment. > >> > >> This is quite different from the Device Tree in the Linux kernel tree, > >> and it hasn't been changed a lot in the last few years. > >> > >> 1) Is there any reason for not sync'ing with upstream Linux kernel > >> instead of having our own Device Tree? > >> 2) Do you think it'd be possible to use OF_UPSTREAM instead which would > >> make it possible to use the device tree from the Linux kernel (it is > >> available in dts/upstream/src/arm/nvidia/tegra20-acer-a500-picasso.dts)? > >> I don't think it's a straightforward thing to do but haven't do it > >> myself, so no clue what's required and the amount of effort to put into > >> it. The benefit is that fixes to the DT will eventually make it to > >> U-Boot as well and we hopefully lower the maintenance burden on U-Boot > >> contributors/maintainers. > >> > >> Cheers, > >> Quentin > > > > Short answers yes and yes. > > > > Long answer: > > 1. Using Linux Kernel device tree will result in at least total > > failure of entire video subsystem since Linux gpu/drm changed > > extremely quick. All devices I have submitted, including A500 heavily > > relay on video output to be operated correctly (being a production > > devices there is no exposed uart or any other output, besides the > > panel). This is only at the first glance, there may be more under the > > surface. At the same time, even if we switch to Linux device trees, > > this will not remove need of *-u-boot.dts to adjust Linux tree to > > U-Boot reality. > > > > Yeah, most if not all our Rockchip-based boards have a -u-boot.dtsi to > fix things up but mainly add binman nodes and add bootph properties > (though those should be upstreamable to the kernel DTS, just that we're > still struggling to get it right on the first try and kernel DTS updates > really takes a long time for us to be merged in U-Boot. > > > 2. It is possible and it is even one of my current priorities. > > Hopefully, by the fall I will be able to configure existing frameworks > > and drivers to comply existing Linux trees. A small example, atm > > U-Boot has no helpers to parse of_graph bindings, which are heavily > > used by Linux to link video devices (that is expected since there is > > not so much devices are using video output so no one bothered). This > > makes most Linux bindings of video devices useless for U-Boot. Don't > > assume that each or nearly each framework has such flows, they are > > uncommon, but nonetheless they occur and destroy full picture. > > I think Qualcomm does have support for display in U-Boot as well, maybe > there's something to be learned/adapted/shared with them as well. >
Qualcomm does not initiate entire video pipe from scratch and does not support use of u-boot as primary bootloader. > In any case, good luck and have fun! > > Cheers, > Quentin
