linux/poky.git/scripts/runqemu, branch 2.6_M3

runqemu: exit gracefully with an error message if qemu system is not evaluated

2018-08-15T08:44:33+00:00

It solves below error: -- snip -- return 'qemu-system-%s' % qbsys UnboundLocalError: local variable 'qbsys' referenced before assignment -- snip -- [YOCTO #12846] (From OE-Core rev: 519273f54c0b8a6fff36afeb7646d8e37717be22) Signed-off-by: Jagadeesh Krishnanjanappa Signed-off-by: Richard Purdie

logging: use warning instead warn

2018-07-26T12:16:40+00:00

The warn method is deprecated. We should use the documented warning instead. Quoting from the python's official doc: """ Note: There is an obsolete method warn which is functionally identical to warning. As warn is deprecated, please do not use it - use warning instead. """ (From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb) Signed-off-by: Chen Qi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

scripts/runqemu: fix qemumips qemumips64 memory detection kernel panic

2018-07-10T16:33:00+00:00

$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512" ... [ 0.000000] Call Trace: [ 0.000000] [] clear_page+0x0/0x128 [ 0.000000] [] get_page_from_freelist+0xab8/0xc00 [ 0.000000] [] __alloc_pages_nodemask+0xdc/0xf68 [ 0.000000] [] __get_free_pages+0x18/0x70 [ 0.000000] [] setup_zero_pages+0x1c/0xb8 [ 0.000000] [] mem_init+0x54/0xa0 [ 0.000000] [] start_kernel+0x204/0x4d8 [ 0.000000] [] kernel_entry+0x0/0x40 [ 0.000000] Code: 02002025 1000f8d9 8e634d7c <34860f80> cc9e0000 cc9e0020 cc9e0040 cc9e0060 cc9e0080 [ 0.000000] [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ... OE uses qemumips to simulate a Malta board by default. As upstream qemu introduced: https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b The Malta board can support up to 2GiB of RAM which should be able to boot a Linux kernel built with CONFIG_HIGHMEM enabled and passing "-m 2048" to QEMU and appending the following kernel parameters: ... mem=256M@0x0 mem=256M@0x90000000 mem=1536M@0x20000000 ... But the following commit in kernel broke above mem=X@Y setting which added the memory as reserved memory area. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ... commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 Author: Marcin Nowakowski Date: Wed Nov 23 14:43:49 2016 +0100 MIPS: fix mem=X@Y commandline processing ... So remove `mem=*' to disable user-defined physical RAM map which let kernel itself caculates memory ranges. Author: Hongxu Jia [ Merge the two fixes for qemumips32 and qemumips64 into one patch, and make it support all mips cases ] (From OE-Core rev: 0220cb34a91658ecc3782ec1a4700dcb5ece37d8) Signed-off-by: He Zhe Signed-off-by: Richard Purdie

runqemu: add SIGTERM handler to make sure things are cleaned up

2018-06-18T10:07:58+00:00

Add SIGTERM handler so that runqemu could clean things up correctly when receving such signal. This problem was originally observed when running testimage. On some hosts, after running testimage task, the user has to manually operate on the tap interface (e.g. `sudo ip link del tap0') in order for the next runqemu command to launch successfully. The problem is about runqemu, SIGTERM and network manager on the host. In testimage task, the runqemu process will receive SIGTERM. In such situation, its cleanup() function is not run, resulting in tap interface not cleaned up. On some hosts, the network manager will bring down the tap interface automatically, thus this problem. I saw this problem on Fedora21. I think we'd better just clean up the tap interface ourselves. So this patch adds to runqemu a SIGTERM handler, in which the actual qemu process is terminated and other things cleaned up. (From OE-Core rev: 02709d4709c56f9b9095e3555da35b659b03a8a3) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

runqemu: Add workaround for APIC hang on pre 4.15 kernels on qemux86

2018-01-02T17:24:39+00:00

On pre 4.15 host kernels, an APIC window emulation bug can cause qemu to hang. On 64 bit we can use the x2apic, for 32 bit, we just have to disable the other timer sources and rely on kvm-clock. [YOCTO #12301] (From OE-Core rev: 82e67b82ea8e12aa0b7b9db1d84fec0436dec71b) Signed-off-by: Richard Purdie

runqemu: Allow the user to override the device tree option

2017-12-02T11:25:34+00:00

Update the runqemu script to allow the user to specify a device tree to boot when calling runqemu. This involves creating a seperate check_dtb() function incase the user has specified 'none' for the kernel but still wants a device tree. (From OE-Core rev: 867ac1370b294bfd1ee31f94abb63688f77081a1) Signed-off-by: Alistair Francis Reviewed-by: Ben Levinsky Cc: Ben Levinsky Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

runqemu: Allow the user to override the Kernel option

2017-12-02T11:25:34+00:00

Update the runqemu script to allow the user to specify a Kernel to boot when calling runqemu. (From OE-Core rev: eaf2793a98cb27d82561da0f8993f2b4b304ecc2) Signed-off-by: Alistair Francis Cc: Ben Levinsky Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

runqemu: print command search result when not found

2017-11-30T10:49:20+00:00

This makes debug easier. (From OE-Core rev: a453639e19fb2a9f9fb63fddd0b3ee26c0116d91) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

runqemu: Also specialcase resolution of '.' to the file's location

2017-11-21T17:58:41+00:00

Similarly to handling "../", handle "." to resovle to the qemuconf file's current directory. (From OE-Core rev: 33418ed064fe9cff5b4803f09135a81d9170c189) Signed-off-by: Richard Purdie

runqemu: Improve relative path handling in qemuconf files

2017-11-21T13:11:03+00:00

If a variable starts with "../", its likely its a path and we want to set it to an absolute path relative to the qemuconf file. This means we don't have to use bitbake as often to figure out variables. (From OE-Core rev: dfc7940900d798aa47716288338107e1d46a3972) Signed-off-by: Richard Purdie