Hi Simon, On Fri, 28 Mar 2025 at 11:13, Simon Glass <s...@chromium.org> wrote: > > Hi Raymond, > > On Fri, 28 Mar 2025 at 08:38, Raymond Mao <raymond....@linaro.org> wrote: > > > > Hi Simon, > > > > On Fri, 28 Mar 2025 at 10:26, Simon Glass <s...@chromium.org> wrote: > > > > > > 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. > > > > > > > I understand that there is a clean-up plan from you, so this time I am > > just trying to minimize the changes (as you can see, just a few lines) > > to make the transfer list work again. > > I am also working on the OP-TEE repo project to enable qemu v8 build > > with transfer list enabled, so users can just use a single command to > > test the Firmware Handoff feature from TF-A to kernel. > > But since 70fe23859437, it is broken in U-Boot due to the overriding > > of the fdt, I made this hotfix in order to let us have the feature > > work again before the upcoming release. > > Yes I looked up that commit but it was over a year ago so I assumed > that something else was going on. >
I was mainly focused on the transfer list path from TF-A through OP-TEE to U-Boot but not much on how U-Boot handles the fdt after it is exacted from bloblist. I just occasionally observed this issue when I was trying to use xtest to run the transfer list unit test I added in OP-TEE a few days ago and found that the OP-TEE commands didn't work at all in the kernel due to the overriding of fdt by that commit. Regards, Raymond > Re your project, it would be good to get that running in CI. My old > standard passage stuff had such a test and I think it was pretty easy > within U-Boot. > > Anyway, this patch doesn't make things any worse. > > Reviewed-by: Simon Glass <s...@chromium.org> > > Regards, > SImon
