OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and tgz]

krisk · Mon Aug 19, 2013 4:19 am

I have purchased a Routerboard 750GL and I'm currently waiting for several PPC-based Routerboards to be shipped.

I'm highly interested in the Metarouter functionality described here:

http://wiki.mikrotik.com/wiki/Manual:Me ... al_machine

I've created a patch against the latest OpenWRT stable release (attitude_adjustment) which compiles MIPS and PPC cleanly as of the latest attitude_adjustment/12.09 rev (r37811). I've updated the kernel patches for PPC and MIPS to support Linux kernel version 3.3.8.

When I boot the MIPS image (RouterOS 6.2 on 750GL) Metarouter reports the machine as "running" and this is the kernel output from the console:

[ 0.000000] Linux version 3.3.8-svn37266 (kris@kkdesk) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #2 Sun Aug 18 14:52:02 EDT 2013
[ 0.000000] CPU revision is: 0001800a (MIPS 4Kc)
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 00029000 @ 003fc000 (usable after init)
[ 0.000000] User-defined physical RAM map:
[ 0.000000] memory: 01000000 @ 00000000 (usable)
[ 0.000000] Zone PFN ranges:
[ 0.000000] Normal 0x00000000 -> 0x00001000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] Early memory PFN ranges
[ 0.000000] 0: 0x00000000 -> 0x00001000
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
[ 0.000000] Kernel command line: console=hvc0 board=vm mem=16M
[ 0.000000] PID hash table entries: 64 (order: -4, 256 bytes)
[ 0.000000] Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[ 0.000000] Memory: 11716k/16384k available (2612k kernel code, 4668k reserved, 437k data, 164k init, 0k highmem)
[ 0.000000] SLUB: Genslabs=9, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS:128
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [hvc0] enabled
[ 0.000000] Calibrating delay loop...

Where it hangs...

I'm betting PPC might "just work" because I had to do far fewer shady things to port it to Linux 3.3.8. Unfortunately I can't test it because I don't have the hardware!

Any help, support, or suggestions would be greatly appreciated. I have the patch and binary images available here:

http://www.kriskinc.com/mikrotik-metarouter

Thanks!

--
Kristian Kielhofner

janisk · Mon Aug 19, 2013 3:53 pm

unfortunately there is no output on the terminal with PPC image.

krisk · Mon Aug 19, 2013 4:59 pm

Thank you for trying my image on PPC hardware; that's not a good sign. I'm still working on MIPS and PPC will have to wait until my hardware gets here.

Thanks again!

--
Kristian Kielhofner

npf · Wed Nov 20, 2013 7:04 pm

Hi Kristian,

Did you get progress for the Mips ?
I'm very interested in a up-to-date openwrt metarouter port.

Thanks
Pierre

NathanA · Wed Jan 08, 2014 3:26 am

unfortunately there is no output on the terminal with PPC image.

This might not have to do with anything that Kristian did wrong with his patch, but might be because of the bug in PPC RouterOS that prevents any custom kernel from booting under RouterOS 6 MetaROUTER (ticket 2013100466000193; see http://forum.mikrotik.com/viewtopic.php ... 7&p=389523). Did you try booting Kristian's PPC image under 5.26?

-- Nathan

janisk · Wed Jan 08, 2014 12:52 pm

yes, the output is the same. That is - no output.

essele · Thu Jan 09, 2014 6:13 am

I've just recreated this exact issue, tested a RB951G originally on 5.25 and now on 6.7.

The MikroTik provided image works fine, a manually built image from OpenWRT svn (as per MikroTik) and patch 1.2 also works fine, but attitude adjustment with the 1.3 patch has absolutely no output at all.

I've been looking at the various patches with a view to porting to a much more recent OpenWRT kernel and I don't think it's quite as simple as just porting the 1.2 patch as there seem to be quite a few significant changes to the mips tree, and even the way the various mips options are structured.

If you look at the 3.3.5 patch that Mikrotik appear to use then you can see quite a few different ways of doing things for the "vm" board type. If you look at the sections within CONFIG_MAPPED_KERNEL you'll see lots of new stuff that wasn't in the 1.2 patch, presumably to deal with changes in the mips implementation.

I think the answer will be a combination of bits of the 1.2 patch and the 3.3.5 patch.

I'm going to see if I can build a vanilla 3.3.5 kernel with the 3.3.5 patch and just hack it into an OpenWRT image, that way I'll know whether it will start to boot or not ... I know it won't subsequently work, but it will make it clear whether it's worth trying to port the 3.3.5 bits to 3.3.8 or later.

Lee.

essele · Thu Jan 09, 2014 2:04 pm

Ok, I've made some progress ... I now have a 3.3.5 kernel which appears to boot. The console isn't working properly, so I don't get any of the boot messages, however I do get the following:

[Ctrl-A is the prefix key]

init started: BusyBox v1.16.1 (2010-04-13 10:25:42 EEST)
/etc/init.d/rcS: line 17: can't open '/dev/null'

At this point my guess is that the startup messages are hidden as this is the same behaviour with the standard non-openWRT metarouters, or it could just be that I'm not using the virtual console properly somehow in my .config ... I will investigate further.

I don't think it will be too much of a stretch to port this to 3.3.8, but I'd like to get to the bottom of the console problem first.

Lee.

essele · Thu Jan 09, 2014 2:13 pm

Update: I've fixed the console by doing a clean build, so it was a problem caused by adding .config items as I was testing.

For reference:

[    0.000000] Linux version 3.3.5 (essele@XXXXXXXXX) (gcc version 4.6.4 (OpenWrt/Linaro GCC 4.6-2013.05 r39203) ) #13 Thu Jan 9 12:04:48 GMT 2014
[    0.000000] CPU revision is: 0001800a (MIPS 4Kc)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 0002a000 @ 003c1000 (usable after init)
[    0.000000] User-defined physical RAM map:
[    0.000000]  memory: 01800000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001800
[    0.000000]   Normal   empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] Early memory PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00001800
[    0.000000] On node 0 totalpages: 6144
[    0.000000] free_area_init_node: node 0, pgdat c03beef0, node_mem_map c1000000
[    0.000000]   DMA zone: 48 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 6096 pages, LIFO batch:0
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 6096
[    0.000000] Kernel command line: console=hvc0 board=vm mem=24M
[    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] Memory: 20200k/24576k available (2433k kernel code, 4376k reserved, 380k data, 168k init, 0k highmem)
[    0.000000] NR_IRQS:168
[    0.000000] console [hvc0] enabled
[    0.000000] Calibrating delay loop... 243.71 BogoMIPS (lpj=487424)
[    0.000000] pid_max: default: 32768 minimum: 301
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] NET: Registered protocol family 16
[    0.000000] bio: create slab <bio-0> at 0
[    0.000000] vgaarb: loaded
[    0.000000] Switching to clocksource MIPS
[    0.000000] NET: Registered protocol family 2
[    0.000000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[    0.000000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.000000] TCP reno registered
[    0.000000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.000000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.000000] NET: Registered protocol family 1
[    0.000000] PCI: CLS 0 bytes, default 32
[    0.000000] MFS init
[    0.000000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.000000] msgmni has been set to 39
[    0.000000] io scheduler noop registered
[    0.000000] io scheduler deadline registered (default)
[    0.000000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.000000] TCP westwood registered
[    0.000000] NET: Registered protocol family 17
[    0.000000] Bridge firewalling registered
[    0.000000] 8021q: 802.1Q VLAN Support v1.8
[    0.000000] VFS: Mounted root (metafs filesystem) readonly on device 0:10.
[    0.000000] Freeing unused kernel memory: 168k freed
/etc/init.d/rcS: line 19: can't open '/dev/null'

Bear in mind this is just a bare kernel build, with minimal config just to get it working, it's not a proper OpenWRT kernel yet. But it's a pleasing start!

Lee.

janisk · Thu Jan 09, 2014 2:37 pm

I've just recreated this exact issue, tested a RB951G originally on 5.25 and now on 6.7.

The MikroTik provided image works fine, a manually built image from OpenWRT svn (as per MikroTik) and patch 1.2 also works fine, but attitude adjustment with the 1.3 patch has absolutely no output at all.

I've been looking at the various patches with a view to porting to a much more recent OpenWRT kernel and I don't think it's quite as simple as just porting the 1.2 patch as there seem to be quite a few significant changes to the mips tree, and even the way the various mips options are structured.

If you look at the 3.3.5 patch that Mikrotik appear to use then you can see quite a few different ways of doing things for the "vm" board type. If you look at the sections within CONFIG_MAPPED_KERNEL you'll see lots of new stuff that wasn't in the 1.2 patch, presumably to deal with changes in the mips implementation.

I think the answer will be a combination of bits of the 1.2 patch and the 3.3.5 patch.

I'm going to see if I can build a vanilla 3.3.5 kernel with the 3.3.5 patch and just hack it into an OpenWRT image, that way I'll know whether it will start to boot or not ... I know it won't subsequently work, but it will make it clear whether it's worth trying to port the 3.3.5 bits to 3.3.8 or later.

Lee.

AFAIK, patch 1.2 has to be updated with stuff from 3.3.5 patch.

NathanA · Fri Jan 10, 2014 2:39 am

The console isn't working properly, so I don't get any of the boot messages...

Update: I've fixed the console by doing a clean build, so it was a problem caused by adding .config items as I was testing.

MikroTik's own kernels have always been configured/patched to not print out boot messages. They do this by redefining the DEFAULT_CONSOLE_LOGLEVEL preprocessor constant in printk.c from 7 to 1. (They only do this in their full kernel patch sets, not the ones that contain only the MetaROUTER subset.) Traditionally, I have simply thrown out their entire patch to printk.c since as far as I can tell, the rest of their modifications to it have to do with providing a hook for RouterOS to intercept printk messages (perhaps for the purpose of being able to collect them and then, say, stash them inside of SUPOUT files?), which we obviously have no use for in OpenWRT.

So your experience is interesting. Perhaps DEFAULT_CONSOLE_LOGLEVEL can be overridden inside of .config, in which case I'm not sure why MikroTik bothers patching the source code file directly.

(To onlookers of this thread, it should be pointed out that the issues with booting MetaROUTER kernels on PowerPC RouterOS are unrelated, and this console 'fix' isn't a solution for that problem. We're only talking about the MIPS kernel port here.)

-- Nathan

essele · Fri Jan 10, 2014 8:00 am

MikroTik's own kernels have always been configured/patched to not print out boot messages. They do this by redefining the DEFAULT_CONSOLE_LOGLEVEL preprocessor constant in printk.c from 7 to 1.

This is really interesting because I left this patch in yet I seem to be having full messages on the console.

I genuinely believe my earlier problem was because I was manually changing .config to add the options one at a time to get the build working, and I wasn't doing a clean rebuild each time, and some of the last adds were around the HVC and VIRTIO.

That said, it doesn't explain why I'm seeing log messages! I'll look at this more closely later.

I got a vanilla 3.3.8 kernel to build and run ok, I'm now fighting with OpenWRT and the sheer scale of their patches that impact the MikroTik kernel stuff.

Lee.

essele · Fri Jan 10, 2014 10:38 am

Ok ... not sure what was happening with the console, it's behaving as expected now.

I have a build of OpenWRT now working with the 3.3.8 kernel, unfortunately there are still issues to be resolved. The failsafe mode works ok, but once it starts trying to load modules you get this:

[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at mm/vmalloc.c:1465 0xc010e084()
[ 0.000000] Trying to vfree() bad address (c0e80e00)
[ 0.000000] Call Trace:[<c03385b4>] 0xc03385b4
[ 0.000000] [<c03385b4>] 0xc03385b4
[ 0.000000] [<c011836c>] 0xc011836c
[ 0.000000] [<c010e084>] 0xc010e084
[ 0.000000] [<c0118420>] 0xc0118420
[ 0.000000] [<c010e084>] 0xc010e084
[ 0.000000] [<c0156510>] 0xc0156510
[ 0.000000] [<c010e6f0>] 0xc010e6f0
[ 0.000000]
[ 0.000000] ---[ end trace a766b1004ee7c11b ]---

I can't say I'm surprised because the whole module.c stuff for relocating modules looks completely different. There's an openwrt patch (305-mips_module_reloc.patch) that looks like it covers all the stuff that the Mikrotik main patch had, so I took most of the Mikrotik stuff out ... perhaps it wasn't the right approach.

[EDIT] I've fixed this issue, it was the is_phys_addr() function. Now it just hangs after loading a few modules. More digging to do...

[EDIT] This is now ok as well (school boy error) ... now I have a "kernel bug" when you have an interface configured. Getting there!

Lee.

essele · Fri Jan 10, 2014 5:14 pm

I've cut a load of stuff out of the patch to try to get back to basics, but I'm still struggling with a bridge related problem:

_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
ATTITUDE ADJUSTMENT (Attitude Adjustment, r39154)
-----------------------------------------------------
* 1/4 oz Vodka Pour all ingredients into mixing
* 1/4 oz Gin tin with ice, strain into glass.
* 1/4 oz Amaretto
* 1/4 oz Triple sec
* 1/4 oz Peach schnapps
* 1/4 oz Sour mix
* 1 splash Cranberry juice
-----------------------------------------------------
root@OpenWrt:/# [ 0.000000] Kernel bug detected[#1]:
[ 0.000000] Cpu 0
[ 0.000000] $ 0 : 00000000 00000063 00000001 00000005
[ 0.000000] $ 4 : c0e8e238 00000000 c03c0860 c0f6e0d0
[ 0.000000] $ 8 : c0f0da74 c038a660 c0f6e120 c0ecf2d0
[ 0.000000] $12 : 00000000 0000000b 00000000 00000001
[ 0.000000] $16 : 00000005 c0e8e238 c0e8e000 c0e8e238
[ 0.000000] $20 : c0e8e000 c03c0860 00000000 00425ac8
[ 0.000000] $24 : 00000018 00800059
[ 0.000000] $28 : c0e30000 c0e31cf0 00410000 c03264c4
[ 0.000000] Hi : 000006fd
[ 0.000000] Lo : 00035f31
[ 0.000000] epc : c01f8dc8 internal_create_group+0x54/0x2dc
[ 0.000000] Not tainted
[ 0.000000] ra : c03264c4 br_sysfs_addbr+0x38/0x114
[ 0.000000] Status: 10008203 KERNEL EXL IE
[ 0.000000] Cause : 00000034
[ 0.000000] PrId : 0001800a (MIPS 4Kc)
[ 0.000000] Process netifd (pid: 1296, threadinfo=c0e30000, task=c0e56088, tls=7782c750)
[ 0.000000] Stack : c038d03d c0ef5df0 c0e8e000 c03bf60c c0ef5df0 c02fa50c 00000005 c0e8e238
[ 0.000000] c0e8e000 c03c0000 c0e8e000 0000000e 00826e3e c03264c4 7f9d5e5c 0000000e
[ 0.000000] 00826e3e 00425ac8 00410000 00000005 c0e8e000 c03a7d6c 00000005 c0e8e000
[ 0.000000] 0000000e c03225e0 00000000 fffffff9 c03c06e0 00000005 c0e8e000 00000000
[ 0.000000] fffffff8 c03a7d6c 00000005 c013c628 c0e8e230 40ff78e9 c0e8e000 00000000
[ 0.000000] ...
[ 0.000000] Call Trace:
[ 0.000000] [<c01f8dc8>] internal_create_group+0x54/0x2dc
[ 0.000000] [<c03264c4>] br_sysfs_addbr+0x38/0x114
[ 0.000000] [<c03225e0>] br_device_event+0x40/0x220
[ 0.000000] [<c013c628>] notifier_call_chain+0x48/0x9c
[ 0.000000] [<c013c7b8>] raw_notifier_call_chain+0x14/0x20
[ 0.000000] [<c02a13b8>] register_netdevice+0x3d8/0x464
[ 0.000000] [<c02a1460>] register_netdev+0x1c/0x38
[ 0.000000] [<c0320d6c>] br_add_bridge+0x3c/0x70
[ 0.000000] [<c03224e0>] br_ioctl_deviceless_stub+0x234/0x298
[ 0.000000] [<c0286c04>] sock_ioctl+0x1b8/0x2f8
[ 0.000000] [<c01ae6d4>] do_vfs_ioctl+0x5ac/0x61c
[ 0.000000] [<c01ae78c>] sys_ioctl+0x48/0x8c
[ 0.000000] [<c010ea90>] stack_done+0x20/0x40
[ 0.000000]
[ 0.000000]
[ 0.000000] Code: 0807e372 00001021 24020001
[ 0.000000] 12c00004 00000000 8e620018 1040008a 2411ffea
[ 0.000000] ---[ end trace 21542e736a48195d ]---

It's all fine up to the point an interface is configured, then I see the kernel bug as above ... experimenting with failsafe it's pretty clear that this is a direct result of adding a 'bridge' rather than eth0. brctl add causes it immediately.

I've spent far too many hours on this today ... will resume tomorrow.

Regards,

Lee.

essele · Fri Jan 10, 2014 9:57 pm

OK ... now it seems to be working ... I've deleted lots of the MikroTik patch, which is a bit of a shame, but now I have a fully functional (at least as far as I have tested) mips Attitude Adjutment build.

I'll try to get back to a controlled state and then post a patch tomorrow.

Regards,

Lee.

essele · Sat Jan 11, 2014 8:39 am

Here is an initial patch ... a few comments:

1. This is against Attitude Adjustment (12.09) r39154.
2. I have only looked at mips, the ppc code is in there but I haven't tested a build or created the target stuff for it
(I don't have a ppc system, so can't test this anyway)
3. This is based on the MikroTik 3_3_5 patch (but applied to 3_3_8.)

I have removed the tile stuff and a few other bits from the 3_3_5 patch, but there is still a lot of stuff in here that isn't needed for metarouter so it's currently much bigger than it needs to be, but it will take a while to unpick as there are lots of dependencies.

My plan at this point is to simplify as much as possible and then see if I can get it ported to trunk.

I'm keen to hear if anyone else gets this to work!

Regards,

Lee.

essele · Sat Jan 11, 2014 3:12 pm

OK, final post for a while (hopefully) ...

I effectively started again only putting in the 3_3_5 patch stuff that I though was necessary, so all of the extra stuff is now removed, this is a much simpler patch, and much closer in spirit to the original 1.2 patch from Mikrotik.

I have produced two patches, one for Attitude Adjustment 12.09 (r39154) and one for the current trunk (r39218) which is kernel 3.10.24.

Some cavates:

1. This is only for mips, I have only tested on the RB951G so far.
2. I have only done very basic testing ... checking it boots and recognises an interface.
3. I am not a kernel or mips expert so I may have broken stuff, especially on the trunk one.

Enjoy, and let me know how it goes.

Regards,

Lee.

essele · Mon Jan 20, 2014 6:24 am

There are still problems with this ... at least on trunk...

[EDIT] This does appear to be only a problem on trunk, it seems ok on 12.09.

root@OpenWrt:/# [ 0.000000] skbuff: skb_over_panic: text:c0256bc4 len:518080 put:518080 head:c0958e80 data:c0958ec0 tail:0xc09d7680 end:0xc0959500 dev:<NULL>
[ 0.000000] Kernel bug detected[#1]:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.24 #1
[ 0.000000] task: c03775b0 ti: c0370000 task.ti: c0370000
[ 0.000000] $ 0 : 00000000 10008200 00000081 c0370000
[ 0.000000] $ 4 : 10008200 00000001 00000000 c03113d0
[ 0.000000] $ 8 : 00001258 c03b30e0 00000001 00000000
[ 0.000000] $12 : ffffff07 0000004b 0000004b 00000000
[ 0.000000] $16 : c0ed6400 c0949760 c03c0000 00000460
[ 0.000000] $20 : 00000118 c03bc8a0 c03c26b4 c03c1698
[ 0.000000] $24 : 00000000 c0111374
[ 0.000000] $28 : c0370000 c0371af0 c0370000 c0267828
[ 0.000000] Hi : 00000000
[ 0.000000] Lo : 72b020c5
[ 0.000000] epc : c0267828 skb_panic+0x58/0x5c
[ 0.000000] Not tainted
[ 0.000000] ra : c0267828 skb_panic+0x58/0x5c
[ 0.000000] Status: 10008202 KERNEL EXL
[ 0.000000] Cause : 00000024
[ 0.000000] PrId : 0001800a (MIPS 4Kc)
[ 0.000000] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ip_tables crc_ccitt ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
[ 0.000000] Process swapper (pid: 0, threadinfo=c0370000, task=c03775b0, tls=00000000)
[ 0.000000] Stack : 00000740 c0355ccc c0256bc4 0007e7c0 0007e7c0 c0958e80 c0958ec0 c09d7680
c0959500 c0350e5c 14e91101 c0269974 00000000 7ed1c3ff c0ed6400 c0949820
c03c0000 c0256bc4 00000001 c007a000 c0371be0 c0e5d230 c087e990 00010000
00000000 00000000 00000043 c037c580 0000000a c0370000 c0370000 c0159d64
c0e5d230 c029a19c c0382dc0 c0949be0 c00bcf10 c0373738 c037c580 00010000
...
[ 0.000000] Call Trace:
[ 0.000000] [<c0267828>] skb_panic+0x58/0x5c
[ 0.000000] [<c0269974>] skb_put+0x48/0x54
[ 0.000000] [<c0256bc4>] veth_interrupt+0x1a0/0x324
[ 0.000000] [<c0159d64>] handle_irq_event_percpu+0x58/0x260
[ 0.000000] [<c0159fa4>] handle_irq_event+0x38/0x5c
[ 0.000000] [<c015c3cc>] handle_edge_irq+0x158/0x1a8
[ 0.000000] [<c0159640>] generic_handle_irq+0x44/0x5c
[ 0.000000] [<c010aa3c>] do_IRQ+0x1c/0x2c
[ 0.000000] [<c0109cbc>] virq_cascade_irq+0x3c/0x70
[ 0.000000] [<c0159d64>] handle_irq_event_percpu+0x58/0x260
[ 0.000000] [<c015cd48>] handle_percpu_irq+0x54/0x88
[ 0.000000] [<c0159640>] generic_handle_irq+0x44/0x5c
[ 0.000000] [<c010aa3c>] do_IRQ+0x1c/0x2c
[ 0.000000] [<c01015c4>] ret_from_irq+0x0/0x4
[ 0.000000] [<c0121098>] __do_softirq+0x9c/0x1d4
[ 0.000000] [<c01212ac>] do_softirq+0x48/0x68
[ 0.000000] [<c01214d8>] irq_exit+0x54/0x70
[ 0.000000] [<c01015c4>] ret_from_irq+0x0/0x4
[ 0.000000] [<c0101860>] __r4k_wait+0x20/0x40
[ 0.000000] [<c01491bc>] cpu_startup_entry+0xc8/0x148
[ 0.000000] [<c038791c>] start_kernel+0x394/0x3b4
[ 0.000000]
[ 0.000000]
Code: afa30020 0c046e60 afa20024 <000c000d> 27bdffc8 afb50024 afb20018 afb10014 afbf0034
[ 0.000000] ---[ end trace 7dff5090af9f2eea ]---
[ 0.000000] Kernel panic - not syncing: Fatal exception in interrupt

I will continue to investigate...

Lee.

nikolasc · Tue Jan 21, 2014 9:48 am

I try to work with the patch for 1209 instead of the official metarouter-1.2 but when I run make menuconfig I cant find Mikrotik MetaROUTER MIPS at Target System.

Do i make something wrong?

essele · Tue Jan 21, 2014 2:19 pm

I try to work with the patch for 1209 instead of the official metarouter-1.2 but when I run make menuconfig I cant find Mikrotik MetaROUTER MIPS at Target System.

Do i make something wrong?

Hi,

You need to download the 12.09 release from OpenWRT using either git or svn...

git clone git://git.openwrt.org/12.09/openwrt.git

Then you need to apply the patch... (replace patch_file with the full or relative path to the patch)...

cd openwrt
patch -p1 < patch_file

Then you should be able to "make menuconfig" and you'll see "Mikrotik MetaROUTER MIPS" under the target systems item.

Regards,

Lee.

nikolasc · Tue Jan 21, 2014 4:15 pm

I was using patch -p0 < according to mikrotik how to build openwrt metarouter image
with patch -p1 < works fine

Very nice job
Thank you

DanielSV · Tue Jan 28, 2014 9:31 pm

OK, final post for a while (hopefully) ...

I effectively started again only putting in the 3_3_5 patch stuff that I though was necessary, so all of the extra stuff is now removed, this is a much simpler patch, and much closer in spirit to the original 1.2 patch from Mikrotik.

I have produced two patches, one for Attitude Adjustment 12.09 (r39154) and one for the current trunk (r39218) which is kernel 3.10.24.

Great work!
One problem preventing it to be usable, though.
Drives the CPU usage of the Routerboard to 100%, which isn't ideal.

liquidcz · Thu Mar 06, 2014 1:34 pm

esselle: Thaks for patch openwrt_metarouter_1209.patch.gz. It looks like its working on official release Attitude Adjusment 12.09 r36088.

Can anybody help me to prepare this patch for mr-ppc?

janisk · Thu Mar 06, 2014 2:41 pm

probably no as there is issue with running OpenWRT as a guest on PPC

First we have to fix that.

npf · Sun May 04, 2014 8:20 pm

Hi Essele and Liquidcz,

Thanks very much for your work. I just tried Liquidcz's rootfs, OpenWrt 12.09 Final with Linux kernel 3.3.8 working out of the box on my RB2011 ! Very nice !

Thanks

okinobk · Thu Oct 30, 2014 12:01 am

probably no as there is issue with running OpenWRT as a guest on PPC First we have to fix that.

Is something new about this issue? I tried compiled image from http://openwrt.wk.cz/attitude_adjustment/mr-ppc/, but it's not booting.
Old images from same site (for example r31411) is working, but it's not stable.

What was changed between these releases, what don't allow boot.

Thanks for help.

OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and tgz]

OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and tgz]

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Re: OpenWRT MetaROUTER with 12.09 and Linux 3.3 [PATCH and t

Who is online