Hi Raymond, On Fri, 28 Mar 2025 at 08:17, Raymond Mao <raymond....@linaro.org> wrote: > > Hi Simon, > > On Fri, 28 Mar 2025 at 07:34, Simon Glass <s...@chromium.org> wrote: > > > > Hi Raymond, > > > > On Thu, 27 Mar 2025 at 17:13, Raymond Mao <raymond....@linaro.org> wrote: > > > > > > When a bloblist is valid and contains fdt, it explicitly means > > > a previous boot stage is passing transfer list compliant with > > > Firmware Handoff specification, thus the fdt from bloblist should > > > not be overridden with the ones from board or env variables. > > > > Why is that? The board can choose to override it, if it wishes, but in > > general, if gd->fdt_blob is already set up, it should return -EEXIST > > from board_fdt_blob_setup(). > > > First, if a board is running in a "stand-alone" mode, there should not > be a transfer list passed from the previous boot stage. > Secondly, overriding the transfer list with the env variables does not > make sense, since booti, bootm and bootefi are actually using the env > variables to get the fdt when launching to the kernel. > We need to do the opposite way - override the env variable with the > one pointing to the bloblist fdt (See my patch [2/2]), then all boot > commands can work with the transfer list.
OK, but now we are going back to the OF_BLOBLIST thing that I did 18 months ago and ended up being the major reason I had to create my own U-Boot tree just to get my boards working. Anyway, Tom has agreed to let me maintain bloblist (and maybe fdt?) again, so I am going to send a series to 'clean this up' as Ilias would say. Let's see if that passes muster, because I do agree with you that if the devicetree is in the bloblist, it should be definitive. Re your second point, do you know why we have fdt_addr? Is it just for the distro scripts? I'm wondering if we could restrict the use of fdt_addr to just the places that actually need to use environment variables. Regards, SImon
