Dear U-boot community! On Mon, Oct 7, 2024 at 12:21 PM Sumit Garg <sumit.g...@linaro.org> wrote: > > On Sat, 5 Oct 2024 at 07:14, Marek Vasut <ma...@denx.de> wrote: > > > > On 9/29/24 9:19 PM, Lothar Rubusch wrote: > > > On Sun, Sep 29, 2024 at 6:55 PM Marek Vasut <ma...@denx.de> wrote: > > >> > > >> On 9/28/24 12:47 AM, Lothar Rubusch wrote: > > >> > > >>>> [...] > > > For U-boot I will need to build a devicetree file from archarm/dts. I > > > cannot rely just on the upstream fragments for u-boot. Imagine > > > settings like initial fpga bitstream loading, handoff file setup for > > > initialization, etc. In parts I may use .dtsi files from dts/upstream, > > > though, but most of the u-boot particular devicetree setup will reside > > > in arch/arm/dts, I guess (you may see later in the patches). > > > > You should be able to use dts/upstream/src/arm/intel/socfpga/ with > > -u-boot.dtsi from arch/arm/dts/ for this purpose, right ? > > Yeah that's a possibility. But are there any plans on pushing > currently U-Boot specific DT bits to upstream DT (Linux kernel > source)? >
Hum, I have certain requirements when working with Arria10 Socfpga SoMs. Here, I need.. - to do the handoff initialization from DTS (only in u-boot) - to setup a fpga loader for the bitstream in the DTS (only in u-boot/spl) - to adjust the boot media, needed for u-boot to know from where to load the fpga.itb - and to mux the boot-mode in the DT, e.g. QSPI off when booting from MMC, and vice versa So, time has passed a bit. I don't need different memory declarations. I don't need DTBOs, but I'm applying the #if IS_ENABLED(CONFIG_..) approach, just great! This reduces complexity by far and I can load the major part from dts/upstream. For the rest I noticed the Google Chameleon HW takes a somehow similar approach and I tried to align my DTS setup to use common base for the handoff and early init approach, which reduces the need to add additional files. Nevertheless, I have to not enable CONFIG_OF_UPSTREAM, since I need to keep the .dts file to reside in arch/arm/dts then taking some of the .dtsi files from dts/upstream. This works and I'll present my solution very soon. > > > > > I noticed when setting the option CONFIG_OF_UPSTREAM in `make > > > menuconfig`, it prepends `dts/upstream/` to the included paths of the > > > devicetree files. The resulting path for the .dts was then > > > dts/upstream/arch/arm/dts/ and could not be found anymore. When I > > > don't activate CONFIG_OF_UPSTREAM, dts/upstream is in the Makefile's > > > include list anyway so that I easily can include from both locations. > > > > +CC Sumit > > > > Yeah that's true it's done on purpose to allow reuse of DT sources > includes (.dtsi or header files) even when CONFIG_OF_UPSTREAM isn't > enabled. > As I said to me this comes in very handy. So, as an update, I started upstreaming of my DTS parts to the kernel, at least Marek should be in CC, here. To the u-boot v3 patch set I prepared further brush ups. I changed over to using standard boot env, and currently pretend removing all of the manually provided env. I tried to get further rid of deprecated things and after a major rework of the DT approach now I have mainly one blocking issue. I'm not sure, perhaps I'll send you the patches together with the question: The altera_set_storage command in the u-boot env was working with the old GPIO API and without using the DM. So, I defined a small U_BOOT_DRIVER(). I don't want to have DT binding for that device, but rather coming up, when I call uclass_get_device_by_driver(). Nevertheless, this function now does not give me a valid device back. IMHO I don't even need an extra bind() or probe(), anyway I tried with/without explicit bind(), with probe(), I tried even to do a crafted binding in the DT with the of_match table. But seems I'm missing something essential. I saw other drivers could use GPIOs relatively simple. Do you know an example where I could have a look at? Then I would use this device and simply implement the altera_set_storage functionaly by the modern GPIO API on the device. I'm a bit unsure what I'm doing wrong here. Perhaps I may show the patches with this issue? Best regards, L
