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. Regards, Raymond > Regards, > SImon
