Hi,
I added the calls and get: Starting kernel fiasco at 00001198 ========================== r0=10001 r1=0 r2=0 r0=ffffffffffffffff r1=80000002 r2=4
Moshe ________________________________ From: Adam Lackorzynski adam@l4re.org Sent: Monday, June 9, 2025 11:12 PM To: Moshe Kravchik mkravchik@hotmail.com; l4-hackers@os.inf.tu-dresden.de l4-hackers@os.inf.tu-dresden.de Subject: Re: Linux fails on startup looking for SMC
Hi Moshe,
Could you place the following code block in l4/pkg/bootstrap/server/src/startup.cc just after the printfs printing "Starting kernel":
printf("==========================\n");
{ register unsigned long r0 asm("r0") = 0x84000000; register unsigned long r1 asm("r1") = 0; register unsigned long r2 asm("r2") = 0;
asm volatile ("smc #0" : "=r"(r0), "=r" (r1), "=r"(r2) : "r"(r0), "r" (r1), "r"(r2) : "memory", "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", "x16", "x17");
printf("r0=%lx r1=%lx r2=%lx\n", r0, r1, r2);
r0 = 0x1; r1 = 0x80000002; r2 = 0x4;
asm volatile ("smc #0" : "=r"(r0), "=r" (r1), "=r"(r2) : "r"(r0), "r" (r1), "r"(r2) : "memory", "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", "x16", "x17");
printf("r0=%lx r1=%lx r2=%lx\n", r0, r1, r2); }
while (1);
The first smc call shall print the PSCI version of the firmware, prints r0=10001 r1=0 r2=0 for me (QEMU). The second part are the values from your debugging, do they print the same?
Adam
On Thu Jun 05, 2025 at 08:47:44 +0000, Moshe Kravchik wrote:
Hi Adam, Did you have any thoughts?
Get Outlook for Androidhttps://aka.ms/AAb9ysg ________________________________ From: Adam Lackorzynski adam@l4re.org Sent: Saturday, May 31, 2025 6:37:43 PM To: Moshe Kravchik mkravchik@hotmail.com; l4-hackers@os.inf.tu-dresden.de l4-hackers@os.inf.tu-dresden.de Subject: Re: Linux fails on startup looking for SMC
Hi Moshe,
I was thinking a bit about this and cannot think of a reason. I'd now try to issue those calls in bootstrap, just to check whether they work from a "bare-metal" environment. And then work from there.
Adam
On Mon May 26, 2025 at 08:49:01 +0000, Moshe Kravchik wrote:
Sorry for a long delay. On this board, there is a Uboot which can load and run Ubuntu. I replaced Ubuntu with L4, which starts a Linux VM that I want to pass the Ethernet to as a passthrough device.
I don't explicitly load ATF, if I understand correctly, it should be loaded before Uboot and therefore before L4 is loaded. I switched to using a kernel from the working Ubuntu image, but SMC calls still return -1 and I can't init the ethernet driver inside the VM. I added prints into the fiasco part and see: vm-1 | [ 17.285888] calling smccc_devices_init+0x0/0xa4 @ 1 vm-1 | [ 17.294574] initcall smccc_devices_init+0x0/0xa4 returned 0 after 0 usecs vm-1 | [ 17.301414] calling smccc_soc_init+0x0/0x2ac @ 1 SMC_USER: kinvoke (1) MC_USER: kinvoke (2) [SMC_USER: kinvoke (3) 3SMC_USER: kinvoke (4) 0x80000001 SMC_USER: kinvoke (5) 7SMC_USER: kinvoke (6) r0 0x1 r1 0x80000002 r2 0x4 r3 0x152b198 mSMC_USER: kinvoke (7) r0 0xffffffffffffffff r1 0xffff40400000 r2 0xffffffffffffffff r3 0x1 vm-1 | vm_call 0x80000001 vm-1 | [ 17.340449] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping .... vm-1 | [ 17.344029] initcall smccc_soc_init+0x0/0x2ac returned 0 after 33538 usecs vm-1 | [ 17.352198] calling zynqmp_firmware_driver_init+0x0/0x34 @ 1 vm-1 | [ 17.360828] probe of firmware:zynqmp-firmware returned 0 after 160 usecs vm-1 | [ 17.368210] initcall zynqmp_firmware_driver_init+0x0/0x34 returned 0 after 7382 usecs
And later: vm-1 | [ 19.699352] calling deferred_probe_initcall+0x0/0xc0 @ 1 vm-1 | [ 19.708582] probe of ff0a0000.gpio returned 517 after 55 usecs vm-1 | [ 19.716071] probe of ff0c0000.ethernet returned -517 after 15 usecs vm-1 | [ 19.723148] zynq-gpio ff0a0000.gpio: deferred probe timeout, ignoring dependency vm-1 | [ 19.731093] zynq-gpio: probe of ff0a0000.gpio failed with error -110 vm-1 | [ 19.740075] probe of ff0a0000.gpio returned 110 after 16951 usecs vm-1 | [ 19.748483] macb ff0c0000.ethernet: deferred probe timeout, ignoring dependency vm-1 | [ 19.756015] probe of ff0c0000.ethernet returned -517 after 7540 usecs vm-1 | [ 19.764931] initcall deferred_probe_initcall+0x0/0xc0 returned 0 after 55255 usecs
Any ideas appreciated, Moshe ________________________________ From: Adam Lackorzynski adam@l4re.org Sent: Tuesday, April 29, 2025 10:57 AM To: Moshe Kravchik mkravchik@hotmail.com; l4-hackers@os.inf.tu-dresden.de l4-hackers@os.inf.tu-dresden.de Subject: Re: Linux fails on startup looking for SMC
If there is a return that's good as there is someone responding. Are you currently running without ATF? Do you just run L4Re instead of Linux or is there some bigger difference?
Adam
On Tue Apr 29, 2025 at 05:50:37 +0000, Moshe Kravchik wrote:
OK, that's great, I just commented out the range check in `fiasco/src/kern/arm/smc_user.cpp`, but even though I see the calls get through, they still return -1. Should I load ATF or some other code first so that someone will respond to these SMC calls? ________________________________ From: Adam Lackorzynski adam@l4re.org Sent: Tuesday, April 29, 2025 12:04 AM To: Moshe Kravchik mkravchik@hotmail.com; l4-hackers@os.inf.tu-dresden.de l4-hackers@os.inf.tu-dresden.de Subject: Re: Linux fails on startup looking for SMC
Hi,
Could you tune ARM_SMC_USER_MIN/ARM_SMC_USER_MAX in the kernel? Seems the SMC functions asked are 0x8200ff03U and 0xC2000xxx and that's not covered by the default range, so increasing ARM_SMC_USER_MAX to 0xcfffffff or so.
Adam
On Mon Apr 28, 2025 at 15:00:04 +0000, Moshe Kravchik wrote:
Thank you! This configuration indeed resulted in the capability present. However, I still get the error: `zynqmp_firmware firmware:zynqmp-firmware: probe with driver zynqmp_firmware failed with error -22` and when I add prints I see that the SMC calls in the Linux kernel return -1. Anything else I need to add to the device tree to initialize it or something? When I boot into Ubuntu without L4 it works. Moshe ________________________________ From: Adam Lackorzynski adam@l4re.org Sent: Monday, April 28, 2025 2:53 PM To: Moshe Kravchik mkravchik@hotmail.com; l4-hackers@os.inf.tu-dresden.de l4-hackers@os.inf.tu-dresden.de Subject: Re: Linux fails on startup looking for SMC
On Mon Apr 28, 2025 at 05:25:34 +0000, Moshe Kravchik wrote:
Thanks a lot, Adam! I added both and rebuilt the device tree, but now I'm getting:
vm-1 | VMM[smccc_proxy]: smccc_proxy vm-1 | VMM: smccc_proxy.l4vmm,smccc_cap: capability smc is invalid. vm-1 | VMM[vm]: Device creation for virtual device smccc_proxy failed. Disabling device.This tells that the 'smc' cap is not there in uvmm. Is it there in the 'caps' table with which uvmm is started? There, where "ram = ..." is as well: caps = { ram = ...., smc = L4.Env.arm_smc, }, .... Additionally, in the microkernel, the CONFIG_ARM_SMC_USER option must also be enabled.
Adam
Moshe ________________________________ From: Adam Lackorzynski adam@l4re.org Sent: Monday, April 28, 2025 12:07 AM To: Moshe Kravchik mkravchik@hotmail.com; l4-hackers@os.inf.tu-dresden.de l4-hackers@os.inf.tu-dresden.de Subject: Re: Linux fails on startup looking for SMC
Hi Moshe,
On Sun Apr 27, 2025 at 15:32:53 +0000, Moshe Kravchik wrote:
Hi, I'm trying to set up a Linux running on uvmm with a HW passthrough. I added `zynqmp_firmware` to my DTS (it was required for the device I'm trying to pass). However, Linux fails to add the device and I see: vm-1 | [ 1.772078] ledtrig-cpu: registered to indicate activity on CPUs vm-1 | VMM[guest]: No handler for SMC call: imm=0 a0=c200003f a1=3f ip=ffff800080026884 lr=ffff800080dcdb04 vm-1 | VMM[guest]: No handler for SMC call: imm=0 a0=c2000001 a1=0 ip=ffff800080026884 lr=ffff800080dcdb04 vm-1 | [ 1.805957] zynqmp_firmware firmware:zynqmp-firmware: probe with driver zynqmp_firmware failed with error -22
>From the traces I added, the failure is in `zynqmp_pm_get_api_version`.
How do I add SMC handling?
You give uvmm in the Ned script: smc = L4.Env.arm_smc
And put this into you device tree: smccc_proxy { compatible = "l4vmm,smccc_proxy"; l4vmm,smccc_cap = "smc"; method = "smc"; };
Note that L4.Env.arm_smc gives access to the real interface with all the power that is behind it (the kernel only filters its range). So in a longer run it might be necessary to have proxy for this interface, or emulate the SMCs, or modify Linux to not use it, whatever fits best.