Hi Raymond, On Mon, 14 Apr 2025 at 18:33, Raymond Mao <raymond....@linaro.org> wrote: > > Hi Simon, > > On Mon, 14 Apr 2025 at 16:47, Simon Glass <s...@chromium.org> wrote: > > > > Hi again Raymond, > > > > On Mon, 14 Apr 2025 at 14:41, Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Raymond, > > > > > > On Mon, 14 Apr 2025 at 14:16, Raymond Mao <raymond....@linaro.org> wrote: > > > > > > > > Hi Simon, > > > > > > > > On Mon, 14 Apr 2025 at 16:06, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > (trimming cc) > > > > > > > > > > Hi Raymond, > > > > > > > > > > On Mon, 14 Apr 2025 at 13:43, Raymond Mao <raymond....@linaro.org> > > > > > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Mon, 14 Apr 2025 at 15:35, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > On Mon, 14 Apr 2025 at 07:08, Raymond Mao > > > > > > > <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Sun, 13 Apr 2025 at 17:13, Simon Glass <s...@chromium.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > On Mon, 7 Apr 2025 at 08:08, Raymond Mao > > > > > > > > > <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > On Sun, 6 Apr 2025 at 18:06, Simon Glass > > > > > > > > > > <s...@chromium.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > > > > > On Sat, 5 Apr 2025 at 07:09, Raymond Mao > > > > > > > > > > > <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 13:40, Simon Glass > > > > > > > > > > > > <s...@chromium.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, 5 Apr 2025 at 03:49, Raymond Mao > > > > > > > > > > > > > <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom and Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 21:00, Raymond Mao > > > > > > > > > > > > > > <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom and Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 20:02, Tom Rini > > > > > > > > > > > > > > > <tr...@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:38:14PM +0000, Simon > > > > > > > > > > > > > > > > Glass wrote: > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 10:18, Tom Rini > > > > > > > > > > > > > > > > > <tr...@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 09:43:54AM -0600, > > > > > > > > > > > > > > > > > > Simon Glass wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The bloblist code took what I consider to > > > > > > > > > > > > > > > > > > > be a wrong turn a year or so > > > > > > > > > > > > > > > > > > > ago. As discussed with Tom, this series > > > > > > > > > > > > > > > > > > > proposes a way to arrange things > > > > > > > > > > > > > > > > > > > so that it is simpler to understand and > > > > > > > > > > > > > > > > > > > manage. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Unwind some of the nesting in > > > > > > > > > > > > > > > > > > > bloblist_init() > > > > > > > > > > > > > > > > > > > - Avoid needing to init the bloblist just > > > > > > > > > > > > > > > > > > > to get the FDT > > > > > > > > > > > > > > > > > > > - Create a deterministic OF_BLOBLIST > > > > > > > > > > > > > > > > > > > option rather than using guesswork > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is to be hoped that we can get a > > > > > > > > > > > > > > > > > > > platform which uses OF_BLOBLIST into > > > > > > > > > > > > > > > > > > > CI at some point. In the meantime, the > > > > > > > > > > > > > > > > > > > standard passage series[1] could > > > > > > > > > > > > > > > > > > > be resurrected to give some coverage. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=281465&state=* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Based on how it's documented to be run in > > > > > > > > > > > > > > > > > > doc/board/armltd/vexpress64.rst in the next > > > > > > > > > > > > > > > > > > branch, have you confirmed > > > > > > > > > > > > > > > > > > that platforms using the handoff spec still > > > > > > > > > > > > > > > > > > work? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe so, yes. I don't have that board to > > > > > > > > > > > > > > > > > test it though. Raymond > > > > > > > > > > > > > > > > > may be able to test this series on QEMU? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was pointing you at the docs so that you > > > > > > > > > > > > > > > > would have access to testing > > > > > > > > > > > > > > > > it. That's part of the docs, running the > > > > > > > > > > > > > > > > emulator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can help to test the firmware handoff on qemu. > > > > > > > > > > > > > > > I have all the necessary changes and unit tests > > > > > > > > > > > > > > > for the OP-TEE repo > > > > > > > > > > > > > > > qemu v8 build to test this. > > > > > > > > > > > > > > > I will try to find some time early next week to > > > > > > > > > > > > > > > review and test this > > > > > > > > > > > > > > > series before turning back to you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just a follow-up on the testing with TF-A and > > > > > > > > > > > > > > OP-TEE. > > > > > > > > > > > > > > Unfortunately, the patch series breaks the transfer > > > > > > > > > > > > > > list handoff to > > > > > > > > > > > > > > U-Boot completely and just end up with below error > > > > > > > > > > > > > > when U-Boot boots: > > > > > > > > > > > > > > ``` > > > > > > > > > > > > > > No valid device tree binary found at > > > > > > > > > > > > > > 0000000000000000 > > > > > > > > > > > > > > initcall failed at call 0000000060097bcc (err=-2) > > > > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot test version: > > > > > > > > > > > > > > 'next' branch + this series + my patch [1] to point > > > > > > > > > > > > > > fdt_addr to gd->fdt_blob. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > https://lore.kernel.org/u-boot/20250331224011.2734284-2-raymond....@linaro.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > I suppose the FDT address in the register is not > > > > > > > > > > > > > being read correctly. > > > > > > > > > > > > > > > > > > > > > > > > > > Do you have a test case for this, e.g. in QEMU? Even > > > > > > > > > > > > > if it is just > > > > > > > > > > > > > binary blobs for now, not suitable for CI, I'd like > > > > > > > > > > > > > to get it in my > > > > > > > > > > > > > lab. > > > > > > > > > > > > > > > > > > > > > > > > > > I did create a test back when I did standard passage, > > > > > > > > > > > > > but that series > > > > > > > > > > > > > seems to have not been applied. I'll see if I can > > > > > > > > > > > > > resurrect it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am using the OP-TEE repo [1] qemu_v8 build to test. > > > > > > > > > > > > You will also > > > > > > > > > > > > need my patch [2] for enabling transfer_ist in all > > > > > > > > > > > > components. > > > > > > > > > > > > > > > > > > > > > > > > [1] https://github.com/OP-TEE > > > > > > > > > > > > [2] https://github.com/OP-TEE/build/pull/821 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tom's email seems easier to follow. I got as far as > > > > > > > > > > > building: > > > > > > > > > > > > > > > > > > > > > > build/fvp/release/fip.bin > > > > > > > > > > > > > > > > > > > > > > But I'm not sure how to run that in QEMU. The docs > > > > > > > > > > > mention some sort > > > > > > > > > > > of FVP thing and running FVP_Base_RevC-2xAEMvA -C which I > > > > > > > > > > > don't seem > > > > > > > > > > > to have. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you want to test with QEMU v8, just simply: > > > > > > > > > > $ repo init -u https://github.com/OP-TEE/manifest.git -m > > > > > > > > > > qemu_v8.xml > > > > > > > > > > $ repo sync > > > > > > > > > > $ cd build > > > > > > > > > > Apply my patch https://github.com/OP-TEE/build/pull/821 > > > > > > > > > > In kconfigs/u-boot_tl.conf, remove 'CONFIG_BLOBLIST_SIZE=0' > > > > > > > > > > and add > > > > > > > > > > 'OF_BLOBLIST=y' > > > > > > > > > > $ make toolchains > > > > > > > > > > $ make run > > > > > > > > > > > > > > > > > > Thanks for the steps. It seemed to complete OK. I also found > > > > > > > > > this: > > > > > > > > > > > > > > > > > > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8 > > > > > > > > > > > > > > > > > > But I'm not sure how to actually run it, or even what was > > > > > > > > > actually > > > > > > > > > built. Do you have the QEMU cmdline I should use to make it > > > > > > > > > start, > > > > > > > > > please? > > > > > > > > > > > > > > > > > > > > > > > > > Besides the steps I mentioned in the previous reply, you will > > > > > > > > need to > > > > > > > > checkout your U-Boot test branch after "repo sync", since by > > > > > > > > default > > > > > > > > the manifest is pointing to an old release. > > > > > > > > "make run" will start the QEMU automatically. > > > > > > > > If you are not sure it is built properly or not, you can use > > > > > > > > "make > > > > > > > > all" to build and "make run-only" for running. > > > > > > > > > > > > > > Well it turns out that it wasn't really building, but the build > > > > > > > produced so many MB of output that this fact was lost in the > > > > > > > noise! It > > > > > > > turned out to be some LD_LIBRARY issue. > > > > > > > > > > > > > > My ideal build would look like this: > > > > > > > > > > > > > > $ make [-s] > > > > > > > <actionable warnings and errors here> > > > > > > > $ > > > > > > > > > > > > > > Anyway, now that I have it running, it's a nice environment, > > > > > > > thank you. I see: > > > > > > > > > > > > > > NOTICE: BL31: Built : 15:06:52, Apr 13 2025 > > > > > > > from_boot_arg 1 > > > > > > > regs 0 0 0 0 > > > > > > > Bloblist at 0 not found (err=-2) > > > > > > > > > > > > > > > > > > > > > U-Boot 2025.04-rc5-00662-gcc30c7943060-dirty (Apr 14 2025 - > > > > > > > 13:25:06 -0600) > > > > > > > > > > > > > > DRAM: 1 GiB > > > > > > > Core: 51 devices, 14 uclasses, devicetree: board > > > > > > > ... > > > > > > > > > > > > > > My code is this: > > > > > > > > > > > > > > int xferlist_from_boot_arg(ulong *addrp, ulong *fdtp) > > > > > > > { > > > > > > > int ret; > > > > > > > > > > > > > > printf("regs %lx %lx %lx %lx\n", saved_args[0], saved_args[2], > > > > > > > saved_args[1], saved_args[3]); > > > > > > > ret = bloblist_check_reg_conv(saved_args[0], saved_args[2], > > > > > > > saved_args[1], saved_args[3]); > > > > > > > if (ret) > > > > > > > return ret; > > > > > > > > > > > > > > *addrp = saved_args[3]; > > > > > > > if (fdtp) > > > > > > > *fdtp = saved_args[0]; > > > > > > > > > > > > > > return 0; > > > > > > > } > > > > > > > > > > > > > > on this tree: > > > > > > > > > > > > > > 37802ca2381 (HEAD) wip > > > > > > > cc30c794306 (el/blob) fdt: Obtain the FDT from bloblist without > > > > > > > parsing it > > > > > > > 4494e4adae0 bloblist: Provide access to the FDT address > > > > > > > ef7193a9f07 fdt: Introduce OF_BLOBLIST > > > > > > > 9e6b2e9c53b bloblist: Simplify bloblist init > > > > > > > 4adbf64ff8d (tag: tmp-patman) Merge branch 'staging' of > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-tegra into next > > > > > > > > > > > > > > which I have pushed to: > > > > > > > source.denx.de:u-boot/custodians/u-boot-dm.git > > > > > > > > > > > > > > in branch 'blob' > > > > > > > > > > > > > > and the build/kconfigs/u-boot_tl.conf file contains: > > > > > > > > > > > > > > CONFIG_BLOBLIST_PASSAGE_MANDATORY=y > > > > > > > CONFIG_OF_BLOBLIST=y > > > > > > > > > > > > > > I don't expect those registers to all be zero. I suppose I am > > > > > > > missing > > > > > > > a config somewhere? > > > > > > > > > > > > > > > > > > > If you already got my changes at: > > > > > > https://github.com/OP-TEE/build/pull/821, and make changes on > > > > > > u-boot_tl.conf on top of it, the only missing thing might be to > > > > > > change > > > > > > "ARM_FIRMWARE_HANDOFF ?= n" to "ARM_FIRMWARE_HANDOFF ?= y" in > > > > > > build/qemu_v8.mk. > > > > > > > > > > OK thanks. But when I do that: > > > > > > > > > > $ make run -j30 -s > > > > > mk/config.mk:520: *** CFG_MAP_EXT_DT_SECURE is set to 'n' (from file) > > > > > but its value must be 'y'. Stop. > > > > > make: *** [common.mk:590: optee-os-devkit] Error 2 > > > > > > > > > > I can see that value in the same build/qemu_v8.mk file. > > > > > > > > > > OPTEE_OS_COMMON_EXTRA_FLAGS += CFG_DT=y CFG_MAP_EXT_DT_SECURE=y > > > > > > > > > > > > > One dependence is at here: > > > > https://github.com/OP-TEE/optee_os/pull/7352/files#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a > > > > > > Thanks, I changed it to n but I still don't see anything in the registers: > > > > > > NOTICE: BL31: Built : 15:06:52, Apr 13 2025 > > > from_boot_arg 1 > > > regs 0 0 0 0 > > > Bloblist at 0 not found (err=-2) > > > > > > > > > U-Boot 2025.04-rc5-00663-g37802ca2381a (Apr 14 2025 - 14:37:38 -0600) > > > > > > I think I need to rebuild BL31. So I'm doing 'make clean' and we'll see. > > > > OK that fixed it. So I'll be able to take a look one of these > > mornings. Thanks for your help. Please get this into CI soon. > > > > No worries, please take your time and feel free to let me know if > there are any questions.
Unfortunately I've broken it again and I'm not sure what is going on. I have burned quite a bit of time on this, unfortunately. Really we need a proper test (within U-Boot) for this. I will send a series which works for that. Once I've sent it, perhaps if you can push a clean tree somewhere with all the optee stuff? Then we should be able to figure out what is wrong. Regards, Simon
