67e41d8a34
The driver tries to access ioports (0x2f9!!) which UML doesn't have. This causes lots of warnings to appear on boot: | WARNING: CPU: 0 PID: 1 at lib/logic_iomem.c:188 serial8250_config_port+0x20a/0x1260 | Invalid writeqb of 0xff at address 2f9 | Modules linked in: | CPU: 0 UID: 0 PID: 1 Comm: swapper Tainted: G W 6.12.25 #0 | Tainted: [W]=WARN | Stack: | Call Trace: | [<60001000>] ? set_reset_devices+0x0/0x16 | [<60452cba>] ? serial8250_config_port+0x20a/0x1260 | [<6071e91f>] ? dump_stack_lvl+0x55/0x71 | [<606e127c>] ? _printk+0x0/0x4f | [<60044bbb>] ? __warn+0x11b/0x120 | [<6003b5d0>] ? um_set_signals+0x0/0x40 | [<606de721>] ? warn_slowpath_fmt+0x81/0x8c | [<606de6a0>] ? warn_slowpath_fmt+0x0/0x8c | [<60452cba>] ? serial8250_config_port+0x20a/0x1260 (they are even recursive!) Now, the situation gets more confusing. Because from what I can tell, this was seemingly done intenionally. Upstream patches in related areas: |commit ddd268c42871b78c75e12a5c28207fb481138f41 |Author: Niklas Schnelle <schnelle@linux.ibm.com> |Date: Wed Apr 3 14:43:00 2024 +0200 | | um: Select HAS_IOREMAP for UML_IOMEM_EMULATION | | In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at | compile time. UML supports these via its UML_IOMEM_EMULATION so let that | select HAS_IOPORT and also reflect this in NO_IOPORT_MAP. hint that there's ongoing work in this area. But unfortunately, this future hasn't arrived yet. Once this future arrives, please nuke this patch. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> |
||
|---|---|---|
| .. | ||
| base-files/etc | ||
| generic | ||
| image | ||
| patches-6.12 | ||
| config-6.12 | ||
| Makefile | ||
| README.md | ||
OpenWrt inside a user mode linux
Why would we even want this many ask?
There are potentially a lot of reasons, one obvious one to me, it allows folks to 'kick the tires' without actually flashing up any hardware. It's also a great environment for porting over packages, you can get a package fully functional in the uclibc root environment inside a uml without actually disturbing your 'real router', and then rebuild for a specific target once it's fully tested.
This is a first stab at a build that 'just works' and there will be more cleanup to come. The simple directions are:-
- Configure for uml target
- Configure with an ext4 or squashfs root file system
- Build it all
In your bin directory you will find a Kernel and an root file system when it's finished. Just run it like this:-
./openwrt-uml-generic-vmlinux ubd0=openwrt-uml-generic-squashfs.img
The uml will start and eventually the serial console of the uml will be at your
console prompt. If you would like it in xterms, substitute con=xterm and
con0=xterm. No networking is configured but it's a starting point. The
resulting file system has just enough free space to start kicking the tires and
playing in the world of 'embedded routers' along with all the resource
restrictions that come with that world.
To configure networking and more refer to the user mode linux documentation
online. A quick start goes along this line. Install the uml-utilities
packages so you have the uml_switch in and running, then add a command param
to your uml start like this:
eth0=daemon,00:01:01:01:01:01,unix,/<your uml switch control socket here>
With that in, and uml networking actually functional (can be a challenge at
times), you should be able to ifconfig the interface and talk to the host
side or if you bridged the uml switch to your host network, you should be able
to run udhcp and be away with networking off to the world. Again, if you are
unfamiliar with uml and uml networking, please read the docs and how-to stuff
available on the net. It does take some fiddling to get it started and working
right the first time, but after that, it opens up a whole new world of virtual
machines.