summaryrefslogtreecommitdiffstats
path: root/meta/conf/machine/qemuppc.conf
Commit message (Collapse)AuthorAgeFilesLines
* qemuboot: Add QB_RNG variableKhem Raj2020-09-241-2/+0
| | | | | | | | | | | | RNG passthru has been enabled on all qemu machines but its being added to each one of them, with this patch its turned into QB variables which defaults to host passthru, yet it can be overridden if needed via machine or config metadata if needed. (From OE-Core rev: 26dd24506ef36088e17f999ce5489dc4b72194e8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemu: uprev v4.2.0 -> v5.0.0Sakib Sajal2020-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Major update after v4.2. Changes: - os_find_datadir() was changed after the v4.2 release causing v5.0 to not find the bios and not boot the image. Fix is sent to upstream qemu. See: qemu/find_datadir.patch - v5.0 binary had host contamination for dynamically linked libraries, "--extra-ldflags='${LDFLAGS}'" in EXTRA_OECONF resolved the issue - bluetooth code was removed: qemu.git$ git show 1d4ffe8dc7 hence removed PACKAGECONFIG[bluez] - -show-cursor qemu option is now deprecated, updated scripts/runqemu to use updated option instead - added PACKAGECONFIG definitions - added qemu-ptest to conf/distro/include/ptest-packagelists.inc - increased support for ARM architecture, cpu and board - removed patches merged upstream and refreshed existing ones Testing: Build core-image-minimal against the machines in openembedded-core/meta/conf/machine and succesfully booted with qemu v5.0 Ran qemu-ptest on x86-64 and arm64 with identical results: PASS: 1166 SKIP: 0 FAIL: 0 (From OE-Core rev: ee9ec9e344541c1ccd9b9b8e3b8c1e00d008ad85) Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com> Signed-off-by: Joe Slater <joe.slater@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machine: clean up config filesJon Mason2019-04-011-2/+2
| | | | | | | | | | Beautify the machine config files by making the names and descriptions more uniform and verbose (From OE-Core rev: 1108a24e2c58794163c8cf35154f8be5c1d06c29) Signed-off-by: Jon Mason <jdmason@kudzu.us> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machine/qemu*: fix kernel finish crng init more and more slowlyHongxu Jia2018-11-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just adding `-device virtio-rng-pci' to the QEMU invocation will add the device with a default host backend. As of QEMU 1.3+, the default backend is to use the host's /dev/random as a source of entropy. [1] When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. [2] For Yocto, if call runqemu frequently, it will consume lots of host's /dev/random, and kernel finish crng init in guest get more and more slowly. Here are 4 times runqemu boot test: [ 3.464432] random: crng init done [ 20.874030] random: crng init done [ 23.583589] random: crng init done [ 23.858945] random: crng init done Modify entropy source to /dev/urandom device on the host which returns random bytes using a pseudorandom number generator seeded from the entropy pool. Reads from this device do not block and kernel finish crng init in guest will not delay. Of course, the side effect is obviously, we lost the quality of randomness, but the modification is only on runqemu script rather than real embedded device, and it benefits oeqa efficiency in which many cases call runqemu especially multiple oeqa builds on one host. After apply the fix: [ 3.364670] random: crng init done [ 4.619061] random: crng init done [ 3.403897] random: crng init done [ 3.450717] random: crng init done [1] https://wiki.qemu.org/Features/VirtIORNG [2] http://man7.org/linux/man-pages/man4/random.4.html (From OE-Core rev: 853644f82eb3205ef3efc1ea3959c7225dfacf61) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemu conf: replace deprecated option with new optionChen Qi2017-08-191-1/+1
| | | | | | | | | | | | Replace the deprecated '-usbdevice' option with '-device usb-xx' option. This would fix runqemu boot error like below. '-usbdevice' is deprecated, please use '-device usb-...' instead (From OE-Core rev: 2f1f3480d344f8521e01f456d2dcd6c4e989ec59) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fixes for slirp, network device and hostfwdRobert Yang2017-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixed: - Add QB_NETWORK_DEVICE to set network device, it will be used by both slirp and tap. - Set QB_NETWORK_DEVICE to "-device virtio-net-pci" in qemuboot.bbclass but runqemu will default to "-device e1000" when QB_NETWORK_DEVICE is not set, this is because oe-core's qemu targets support virtio-net-pci, but the one outside of oe-core may not, "-device e1000" is more common. - Set hostfwd by default: 2222 -> 22, 2323 -> 23, and it will choose a usable port when the one like 222 is being used. This can avoid conflicts when multilib slirp qemus are running. We can forward more ports by default if needed, and bsp.conf can custom it. - Use different mac sections for slirp and tap to fix conflicts when running both of them on the same host. [YOCTO #7887] CC: Nathan Rossi <nathan@nathanrossi.com> CC: Randy Witt <randy.e.witt@linux.intel.com> (From OE-Core rev: 7dddd090806914a62d977730440d803e48f44763) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Use weak assignment for SERIAL_CONSOLES in qemu configuration filesChen Qi2016-12-131-1/+1
| | | | | | | | | | | | | | | | | Use weak assignment for SERIAL_CONSOLES in qemu configuration files so that the value could serve as a default value and could be easily overridden in configuration files like local.conf. When using the default value for SERIAL_CONSOLES in qemux86-64,we would have annoying messages on console complaining about respawning getty on ttyS1. Although the value is set by purpose, at least we need to provide an easy way to override it. (From OE-Core rev: 5f060b66162c41a295995947b918253450870117) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machine/qemu*: Add comment regarding the reason for virtio-rng-pciNathan Rossi2016-09-281-0/+1
| | | | | | | | | | | Bring across the comment that was in runqemu regarding why the virtio-rng-pci device was needed. This comment is added to each location where the virtio-rng-pci device is added. (From OE-Core rev: bc5d1fdea674e842e4b0c45b38782930ec133051) Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Move virtio RNG to machine configurationNathan Rossi2016-09-231-1/+1
| | | | | | | | | | | | | | | | | Not all QEMU machines (outside of those available in OE-Core) are capable of using the virtio-rng-pci device due to various machine models not having a pci/virtio bus. This makes it such that the use of the '-device virtio-rng-pci' flag to QEMU is machine specific. This patch removes the general addition of the flag to all runqemu targets and adds the flag into the QB_OPT_APPEND for all the qemu* machines in OE-Core that support its use (which is all of them). (From OE-Core rev: e890c05e66a21702e9e8ccce794b74cb7f5518ed) Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuppc.conf: adjust kernel consoleRobert Yang2016-09-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed kernel trace when booting: [ 12.825809] random: crng init done [ 13.918323] irq 36: nobody cared (try booting with the "irqpoll" option) [ 13.924821] CPU: 0 PID: 335 Comm: getty Not tainted 4.8.0-rc5-yocto-standard #1 [ 13.930492] Call Trace: [ 13.936214] [cff73f20] [c00790f0] __report_bad_irq.isra.0+0x3c/0x128 (unreliable) [ 13.941908] [cff73f40] [c0079518] note_interrupt+0x2b8/0x304 [ 13.947265] [cff73f70] [c00766f4] handle_irq_event_percpu+0x5c/0x74 [ 13.952503] [cff73f90] [c0076768] handle_irq_event+0x5c/0xdc [ 13.957667] [cff73fa0] [c007a29c] handle_fasteoi_irq+0xdc/0x234 [ 13.962984] [cff73fc0] [c007592c] generic_handle_irq+0x3c/0x58 [ 13.968288] [cff73fd0] [c0006c74] __do_irq+0x54/0x18c [ 13.973612] [cff73ff0] [c000f9c8] call_do_irq+0x24/0x3c [ 13.978742] [cf0cdb70] [c0006e40] do_IRQ+0x94/0x110 [ 13.983992] [cf0cdba0] [c001215c] ret_from_except+0x0/0x14 [ 13.989281] --- interrupt: 501 at pmz_set_termios+0x130/0x6d8 [ 13.989281] LR = pmz_set_termios+0xf0/0x6d8 [ 13.999353] [cf0cdc90] [c049f130] uart_change_speed.isra.2+0x60/0x168 [ 14.004436] [cf0cdcb0] [c049fdbc] uart_startup.part.8+0xec/0x1e0 [ 14.009625] [cf0cdce0] [c04a0ab4] uart_open+0x138/0x16c [ 14.014723] [cf0cdd00] [c047e510] tty_open+0x118/0x65c [ 14.019743] [cf0cdd60] [c01894c8] chrdev_open+0xdc/0x1e0 [ 14.024616] [cf0cdd90] [c01807d0] do_dentry_open+0x23c/0x358 [ 14.029418] [cf0cddc0] [c0194878] path_openat+0x58c/0x1084 [ 14.034054] [cf0cde50] [c01965b4] do_filp_open+0xbc/0x10c [ 14.038539] [cf0cdf00] [c01822fc] do_sys_open+0x154/0x224 [ 14.043105] [cf0cdf40] [c0011a44] ret_from_syscall+0x0/0x38 [ 14.047828] --- interrupt: c01 at 0xfeef5a0 [ 14.047828] LR = 0xfeef544 [ 14.056543] handlers: [ 14.060980] [<c04a2b10>] pmz_interrupt [ 14.065468] Disabling IRQ #36 (From OE-Core rev: 7c6d0e4ada6dea6ac994e637b7d5cf007f73e411) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Allow unique network interface MAC addressesRichard Purdie2016-09-091-1/+1
| | | | | | | | | | | Current qemu instances all share the same MAC address. This shouldn't be an issue as they are all on separate network interfaces, however on the slight chance this is causing problems, its easy enough to ensure we use unique MAC addresses based on the IP numbers we assign. (From OE-Core rev: c01962bf88786dd84ad83cc1d315297607d29f7c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuppc: Use virtio networking instead of pcnetRichard Purdie2016-09-091-1/+1
| | | | | | | | | qemuppc can use virtio networking and we may as well do so for better prformance as we do under the other emulated hardware. (From OE-Core rev: 8a82ded799be79eacb64cf313b6f2799a4f5ffab) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuppc.conf: set vars for runqemuRobert Yang2016-09-091-0/+7
| | | | | | | (From OE-Core rev: 2c8e5657cafafe848c7e7c714e5e73bb82799d65) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc, qemuppc: Explicitly disable forcing SPE flagsKhem Raj2016-01-311-0/+2
| | | | | | | | | | | | | | | | | | | | | G4 does not have SPE, so we make that explicit in the tune files and since we emulate G4 when building Qemu, we ensure it for qemuppc as well. GCC config for powerpc-linux is made to include SPE by default which is equivalent if the tripet was powerpc-linux*spe, this forces gcc to configure assembler to enable -mspe by default, when we do that then the kernel fails to compile with binutils 2.26, since newer assembler is smart to detect the tlbia instructions are not compatible with SPE and hence the kernel build breaks rightly. We configure the kernel for G4 as well where it enables tlbia instrucitons rightly so because it thinks its being configured for power4. So we keep the options but do not force -mspe down to assembler as default. (From OE-Core rev: 7a51776a830167e43cbd185505f62f328704e271) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemurunner: Use two serial ports and log console with a threadRandy Witt2015-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | qemu can freeze and stop responding if the socket buffer connected to a tcp serial connection fills up. This happens of course when the reader of the serial data doesn't actually read it. This happened in the qemurunner code, because after checking for the "login:" sentinel, data was never again read from the serial connection. This patch solves the potential freeze by adding a thread to continuously read the data from the console and log it. So it also will give a full log of the console, rather than just up to the login prompt. To simplify this patch, another serial port was also added to use for the sole purpose of watching for the sentinel as well as being the interactive serial port. This will also prevent the possibility of lots of debug data on the console preventing the sentinel value from being seen due to interleaved text. (From OE-Core rev: 2da3fee6b6d9f4dd4c4cb529f4ba393c20aa0f13) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuppc: Change default tune to 74xxKhem Raj2013-08-201-1/+1
| | | | | | | | | | | We use mac99 as platform for qemuppc lets choose a tuning thats appropriate for it (From OE-Core rev: 9b5572b8014f23747f18a7e0ca30c7094c524920) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuppc: replace emulation of qemuppc from prep to mac99Liming Wang2012-01-171-1/+1
| | | | | | | | | | | | With this new emulation, existing qemuppc functionality is maintained and other functionality such as framebuffer + sato and NFS boot are added. (From OE-Core rev: 52ea026df141ea23bbab38ad3a9733c15097eaa4) Signed-off-by: Liming Wang <liming.wang@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* conf/machine: Don't poke around providers which aren't machine specific/safeRichard Purdie2011-12-061-2/+0
| | | | | | | | | | | | Machines shouldn't be poking around PREFERRED_PROVIDERS which aren't machine specific or at least machine safe. Kernels are machine specific and the xserver is selectable. libx11 and mesa are now really a distro choice and machine configurations shouldn't be poking around them as it just leads to corruption, conflicts and confusion. (From OE-Core rev: 97a57aca12437c24b628071bb189c9f3b94e27ca) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* conf/machine/tune: Overhaul tune include file variablesRichard Purdie2011-07-251-2/+0
| | | | | | | | | | | | | | | | | | | | | | There is currently consideradble confusion over how the tune files operate and how these interact with the rest of the build system. This update/overhaul changes things so the tune files are primarily resonsible for setting: TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value that represents the architecture we're targetting. TUNE_PKGARCH - The value that represents the tune confuration that this set of tune parameters results in. This allows the significant improvement that the core can now always determine the target architecture value, even when TARGET_ARCH needs to be reset to something different and likewise, there is one package architecture variable the core can reference allowing simplification of the BASE_PACKAGE_ARCH, PACKAGE_ARCH and FEED_ARCH variables. (From OE-Core rev: a10de4cf8b424ee95c8e283e75d486be5b3b8eac) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuppc: add libqtopengl4 for ppcMei Lei2011-04-041-0/+2
| | | | | | | | | | Modify some configs for ppc to enable the libqtopengl4 support. This fixes [YOCTO #848] (From OE-Core rev: cc6763b81fafddcb112a6126373c594e3ec4b140) Signed-off-by: Mei Lei <lei.mei@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machines: move PACKAGE_EXTRA_ARCHS to tune filesKoen Kooi2011-01-101-1/+0
| | | | | | | | This gets us closer to making including tune-<arch>.inc "just work". Moving the TARGET_ARCH definitions is something for a follup patch. Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemu machines: Switch to use linux-wrsBruce Ashfield2010-07-191-1/+1
| | | | Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* qemuppc: Add ppc603e to PACKAGE_EXTRA_ARCHS, fixing image buildsRichard Purdie2010-06-111-0/+1
| | | | Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* Move all QEMU machines to use a common kernel recipe set and versionJoshua Lock2010-05-181-1/+0
| | | | | | | | | | | The different kernel recipes encapsulate functionality groups for machines, therefore it makes sense to have all the QEMU machines using the same kernel recipe. Switch the QEMU machines to default to the "linux" recipes for their kernel and bump the latest recipe from linux-2.6.32 to 2.6.33. Signed-off-by: Joshua Lock <josh@linux.intel.com>
* qemuppc: Add qemuppc machineJoshua Lock2010-01-191-0/+14
Signed-off-by: Joshua Lock <josh@linux.intel.com>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 03:03:21 +0000