Dear U-boot community!
On Mon, Oct 7, 2024 at 12:21 PM Sumit Garg sumit.garg@linaro.org wrote:
On Sat, 5 Oct 2024 at 07:14, Marek Vasut marex@denx.de wrote:
On 9/29/24 9:19 PM, Lothar Rubusch wrote:
On Sun, Sep 29, 2024 at 6:55 PM Marek Vasut marex@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