RE: schedule() or scheduler_tick() not called during qemu run
Just to let you know I solved this boot problem by
1. adding gic initialization in u-boot (using CONFIG_GICV3),
2. adding code to power up GICR (percpu) using GICR_PWRR register.
3. and enabling system counter(FREQ value, enable), and EL1 physical timer
(TVAL, enable, interrupt mask setting)
This made uart interrupt and timer interrupt working hence the scheduler by
timer and the shell program.
It turned out u-boot should do these things. (arm reference software's
arm-tf is a good reference and the newest u-boot didn't have these GICR_PWRR
things)
The boot is ok and shell runs ok in the FPGA board.
Hope this helps someone later.
Chan Kim
>-Original Message-
>From: Chan Kim
>Sent: Monday, August 29, 2022 3:42 PM
>To: 'qemu-discuss@nongnu.org'
>Subject: schedule() or scheduler_tick() not called during qemu run
>
>Hello qemu experts,
>
>I'm trying to debug a situation where the /init script is processed at the
>end of the kernel_init function which is the final stage, but the last
>command in the /init script which is 'exec /bin/sh' hangs after the first
>call and return of schedule() function in my fpga test. The file system is
>initramfs.cpio.gz and was made using busybox. If I replace the /init scritp
>with a program which repeats printf("hello %d", cnt++), it stops after
>117~118 times and I can see schedule() was called and finished before it
>hangs.
>So I tried to follow what's happening using qemu (though the virtual
>machine is not exactly the same with the actual board), but when I set
>breakpoint in schedule() or scheduler_tick(), the breakpoint never kicks
>in(Of course other break points all work). Is this normal in qemu or is
>there something wrong in my qemu execution(I mean in my virtual machine)?
>BTW, this is an arm64 board.
>
>Chan Kim
Re: If your networking is failing after updating to the latest git version of QEMU...
On 2022-09-29 08:34, Thomas Huth wrote: On 29/09/2022 04.32, Jason Wang wrote: On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé wrote: On 28/9/22 10:27, Thomas Huth wrote: ... it might have happened due to the removal of the "slirp" submodule from the git repository. For example if you see an error message like this: Parameter 'type' expects a netdev backend type this likely means that the "user" mode backend type is not available in your binary anymore. To fix it, simply install "libslirp-devel" (or libslirp-dev or however it is called) from your OS distribution and recompile. Thanks for the hint Thomas. I'm afraid many developers will miss your email. Jason, Marc-André, could we improve the buildsys check or display a more helpful information from the code instead? It looks to me we need to improve the build. I'm not sure there is anything to improve in the build system - configure/meson.build are just doing what they should: Pick the default value for "slirp" if the user did not explicitly specify "--enable-slirp". But the error message is not very helpful. It should rather say something like (partly suggested by Daniel in IRC yesterday already): Type 'user' is not a supported netdev backend by this QEMU build. Please check the spelling or whether it has been enabled at compilation time. ... or something like this. Someone interested to write a patch? Maybe a more actionable error message such as: Type 'user' is not a supported netdev backend by this QEMU build because the libslirp development files were not found during build of QEMU. The condition for this error message should be that both the user backend is not compiled AND the build system did not detect libslirp. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
