As a future enhancement, it would make sense to improve support Altera/Nios2. Nios2 is a one of the Linux supported architectures. There are patches for QEMU to support Nios2 CPU, including MMU. (There is an effort to upstream the support to QEMU mainline). This would tie in nicely with some other enhancements, as is for example a currently under review planned support for Zephyr (which supports Nios2). It would make also sense as a multiconfig use case, where there is a potential need to build two distinct (but associated) images: one for Intel architecture and one for Altera/Nios2. There are several hw Altera platforms, I believe Zephyr uses this one: https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-max-10m50-evaluation.html The support can be provided via a separate meta-layer, or directly in oe-core (poky).
Things just got a bit easier as Altera/Nios2 are now natively (as of today!) supported by upstream QEMU.
I pushed the related changes here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jurob/qemunios2 It is now possible to run $ MACHINE=qemunios2 bitbake core-image-minimal $ runqemu qemunios2 QEMU emulates the Altera/Nios2 hw: CPU + MMU, intc, jtag-uart, serial uart, timers, Ethernet network controller. It is possible to boot a Linux image (initramfs)
After booting Linux, we can query interrupts and CPU: root@qemunios2:~# cat /proc/interrupts CPU0 1: 6966 NIOS2-INTC 0 timer 2: 59737 NIOS2-INTC 1 serial 3: 7 NIOS2-INTC 2 eth0 4: 0 NIOS2-INTC 3 eth0 root@qemunios2:~# cat /proc/cpuinfo CPU: Nios II/fast MMU: present FPU: none Clocking: 75.00 MHz BogoMips: 150.00 Calibration: 75000000 loops HW: MUL: yes MULX: no DIV: yes Icache: 32kB, line length: 32 Dcache: 32kB, line length: 32 TLB: 16 ways, 256 entries, 8 PID bits
For 2.4 can we support a basic qemu machine within OE-Core? Is that a reasonable thing to target?
(In reply to comment #4) > For 2.4 can we support a basic qemu machine within OE-Core? Is that a > reasonable thing to target? Yes, it should be reasonable. The QEMU master already has support for Nios2, so the next QEMU release should make it official. However, QEMU is just one part, obviously we also need to support Nios2 toolchain. This is not difficult either, but it would be nice not to have to use meta-altera layer where various tunes are defined. We should probably also define a corresponding HW reference platform to make sure HW and QEMU behave identically.
These are the steps that allow reproducing the build. $ git clone https://git.yoctoproject.org/git/poky-contrib $ cd poky-contrib/ $ git checkout 52f5276976d9fe2a695ae7ca558d3234335d6adf $ source oe-init-build-env build-qemunios2 $ MACHINE=qemunios2 bitbake core-image-minimal ...wait for build to finish ... $ runqemu qemunios2 There will be some warnings during the build, but they can be ignored.
Master now supports/builds Nios2 qemu http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7f45ea5083b845490bc3db2a449b6e8b71 With the layer meta-altera it is fairly simple to build core-image-minimal (with initramfs) and run this image on 10m50 Altera board (with GHRD FPGA flashed). It is also possible to boot the image via u-boot over Ethernet. However, moving to 2.5 as some documentation and additional testing is required.
Please provide an update on the status of this and let me know if it will be ready for YP 2.5 M3.
As per Juro's comment the work is done and this was just pending documentation which someone could add if they so wish but nobody seems willing, resolving as fixed.