Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kirkwood [RFC]: switch to 4.9 #1019

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
6 participants
@p-wassi
Copy link
Contributor

commented Apr 1, 2017

Maintainer: @lperkov @mkresin @bobafetthotmail
Compile tested: kirkwood-*
Run tested: kirkwood-dockstar

Switch to kernel 4.9 for kirkwood. (Based on 4.9.20)
A bit more detailed description + bootlog of dockstar is available at 1

Some DTS files are now included in kernel. Then, for the patches:
160-ea4500 is dropped since already included in kernel.

  • DTS: "model" name has been changed -> therefore also done in /lib/kirkwood.sh
  • DTS: "chosen" has been changed - does this affect anything?
  • DTS: switch "mvsw61xx" was replaced by "dsa", eth1 port disabled, therefore removed from switch config
  • DTS: kernel partition sizes were changed (they were overlapping with rootfs)
  • DTS: partitions were renamed -> do that in /lib/upgrade/linksys.sh as well

170-ea3500

  • undergoes the same changes that were made in 160-ea4500 to match the structure of that file

191-nsa310b

  • Is derived from upstream available nsa310a, simplifies DTS

192-nsa310s

  • Rewritten to make use of common dtsi file.
  • DTS: "compatible" string says "nsa320s", is this a typo and should be "nsa310s"?
  • General: I can't select this target in make menuconfig. Why is there this patch?

194-nsa325

  • Is included in kernel, just the default LED triggers are kept here

Add config-4.9, which basically is a copy'n'paste from different 4.9 targets.

I've successfully compile tested these changes for every target, but could only run-test it
on Dockstar since I don't have any of the other devices.
Especially important for reviewing:

  • config-4.9
  • linksys-viper (can s/o run-test it?)
  • linksys-audi (can s/o run-test it?)
  • nsa3xx devices (can s/o run-test it?, @bobafetthotmail ?)

@pepe2k pepe2k added the kirkwood label Apr 1, 2017

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2017

DTS: "compatible" string says "nsa320s", is this a typo and should be "nsa310s"?

AFAIK the nsa320s and nsa310s are pretty much the same, the 320s has 2 sata (and has a bigger box) but they are otherwise identical.

General: I can't select this target in make menuconfig. Why is there this patch?

it seems initial support was added 6a18146
but then not hooked up beyond that point nor updated.
I know the nsa310s was upstreamed in u-boot, maybe also in linux kernel. Same Tony Dinh and Luka Perkov in the signed-off-by.

It seems Tony "Dinh" got fed up of upstreaming and went off to make his own "Debian ARM for kirkwoods" here http://forum.doozan.com/read.php?2,12096 (yes that's the same person), that I used as a base to add support for nsa310/325.

nbd168 dumped the image-building code when migrating to modern image building system, as it was not functional by then
2eb1cc3

So that patch is unused, like some other remains in board scripts.

194-nsa325 Is included in kernel, just the default LED triggers are kept here

Please drop them too, I have a PR that deletes them and uses uci led setup instead #938

nsa3xx devices (can s/o run-test it?...

Will do this in a few days, thanks. :)

@p-wassi p-wassi force-pushed the p-wassi:kirkwood_49 branch 2 times, most recently from 8b11c6e to 6b6c8c8 Apr 1, 2017

@p-wassi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2017

nsa320s and nsa310s are pretty much the same, the 320s has 2 sata

Ah, okay. The DTS specifies

&sata {
status = "okay";
nr-ports = <2>;
};

So probably the file should be renamed to nsa320s then?

So that patch is unused, like some other remains in board scripts.

Hmmm... who can decide on this?

Please drop them too, I have a PR that deletes them and uses uci led setup instead

I now dropped those for nsa325 and nsa310s. There's still two default-triggers in the
DTS for goflexhome. Can we move them to your uci led setup in the same turn?

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

There's still two default-triggers in the DTS for goflexhome. Can we move them to your uci led setup in the same turn?

Probably not in the same PR as my nsa3xx, since the ide-disk trigger should be changed anyway to disk-activity in kernel 4.9, it makes sense to add it here, or in a new PR after this.

EDIT: btw, tested on nsa310b and nsa325 and it works fine so far.

@p-wassi p-wassi force-pushed the p-wassi:kirkwood_49 branch from 6b6c8c8 to d93b475 Apr 8, 2017

@p-wassi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 8, 2017

since the ide-disk trigger should be changed anyway to disk-activity in kernel 4.9

Thanks for the hint, it is changed to disk-activity in this commit for now.

tested on nsa310b and nsa325 and it works fine so far.

Ah, fine. Thank you for testing!

@p-wassi

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2017

Just tested on Dockstar: still applies to 4.9.30.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2017

could you refresh the patch to include the changes from my commit about leds? f7fd2ab
It needs some options added to kernel config and a one-liner kernel patch

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2017

I did that on my side and it works fine on nsa325
please add these options in the 4.9 kernel config
CONFIG_ARCH_WANT_LIBATA_LEDS=y
CONFIG_ATA_LEDS=y
CONFIG_USB_LED_TRIG=y

and place this patch in the patches-4.9 folder

https://www.dropbox.com/s/fks7yqqomkgpw7i/patch.zip?dl=0 (github does not seem to like this file for some reason)

and it should be ok.

@p-wassi p-wassi force-pushed the p-wassi:kirkwood_49 branch from d93b475 to 3d9e760 Jun 6, 2017

kirkwood: switch to 4.9
Switch to kernel 4.9
Add patches-4.9, some of them (heavily) rewritten:
  - 160-ea4500 is dropped, since already upstream
  - 170-ea3500 is changed to match the structure of 160-*
  - 192-nsa310s rewritten to include the common dtsi
  - 194-nsa325 is dropped, since already upstream
Add config-4.9

Signed-off-by: Paul Wassi <p.wassi@gmx.at>
@p-wassi

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2017

Thanks for adding this comment @bobafetthotmail - I've just included your contribution
into the commit (i.e. the config symbols and 210-*.patch are added)

@diizzyy

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2017

Tested and working on iOmega iConnect, thanks!

There one "bug" however, console (serial) stops working during bootup. The device boots fine so it's a minor issue...

[   16.020509] br-lan: port 1(eth0) entered blocking state
[   16.025804] br-lan: port 1(eth0) entered forwarding state
[   16.081588] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
....freezes here.....

@nbd168
Can we merge this?

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2017

Sounds like device-specific, as serial console on nsa3xx devices works fine with this patch.

@p-wassi

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2017

@diizzyy I guess, the serial console was working with 4.4 on iConnect?
Actually, nothing relevant was changed in the upstream DTS (bootargs
is still console=ttyS0,115200n8 earlyprintk)

What about sending strings to some /dev/tty* for testing?
Like echo asdf > /dev/ttyS0, .../ttyS1, ...

What's also strange: for me, after
[ 16.081588] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
there's just random: nonblocking pool is initialized - and that's it. All the console
stuff happens far earlier on a dockstar:
[ 0.170130] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[ 0.173123] console [ttyS0] disabled
[ 0.173193] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 25, base_baud = 12500000) is a 16550A
[ 0.624571] console [ttyS0] enabled

Yeah, this seems to be a device-specific issue. However, I'm curious what the reason is...

@diizzyy

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2017

@p-wassi
It was, unfortunately I don't have serial access to those boxes right now so I can't do any further testing. I figured that you should know at least.

@diizzyy

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2017

Added some notes by @mkresin on request (rephrased):
The change of switch driver needs to be tested by EA3500/EA4500 users as regression will be no network connectivity. MVSW61XX_PHY is the LEDE/OpenWrt switchdev based switch driver and is still included but not used in dts anymore. The DSA driver is from upstream (just to clarify).

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2017

I was wrong in my chat with @diizzyy. Sorry about that! Let me add the missing pieces.

The linksys boards have the mv88e6176 switch and at the moment neither the upstream DSA based mv88e6176 driver nor the LEDE/OpenWrt switchdev based mv88e6176 driver is enabled properly.

The LEDE/OpenWrt switchdev driver (MVSW61XX_PHY) requires a switch node with the compatible string "marvell,88e6171" in the dts. It is missing.

The upstream DSA driver isn't enabled at all in the kconfig (CONFIG_NET_DSA_MV88E6XXX).


At the moment we can not switch to the upstream DSA based driver.

With the LEDE/OpenWrt switchdev based drivers the well known config is added with:

ucidef_add_switch "switch0" \
	"0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" "6@eth1"

With DSA based switch drivers, for each switch port will be an netdev created (named by the label property of the switch node in the device tree source file) and we only need to bridge the lan interfaces.

It would require the following uci_def* instead:

ucidef_set_interfaces_lan_wan "ethernet1 ethernet2 ethernet3 ethernet4 " "internet"

The problem we have, are already deployed linksys-viper/linksys-audi boards. If someone does an update and keep the settings, the ethernet will most likely not work. At the moment we do not have a script to migrate switchdev based configs in /e/c/network to the syntax required for DSA based drivers.

We do have the same problem with the mvebu target. The mvebu solution is to not enable the marvel DSA driver in the kernel config, add the mv88e617* switchdev driver relevant node(s) to the dts and use the switchdev based driver instead.

IMHO, the same should be done for the kirkwood linksys boards as well.

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2017

I've merged a modified version of the PR to my staging tree. I felt it is easier to fix the small issues I found by my self instead of playing ping pong. Nevertheless, excellent work so far @p-wassi.

I've backported the linksys kernel 4.9 dts changes to the 4.4 dts files. This way we can add optional 4.9 support and hopefull find someone to test the linksys boards with 4.9.

I've refreshed the kernel config. The one from the PR seams to me hand crafted and had a lot of stuff which isn't in kernel 4.9 any longer. make kernel_menuconfig or make kernel_oldconfig is the way to update the 4.4 config for 4.9.

@bobafetthotmail While doing a compile test I've spotted a new hw monitoring module:

ZyXEL NSA320 and compatible fan speed and temperature sensors (SENSORS_NSA320) [N/m/?] (NEW)

Might be interesting for you.

@p-wassi @bobafetthotmail @diizzyy Would you please runtime test the commits in my staging tree? I don't like to commit stuff that I potentially broke. Please leave a note here about which board you have tested and whether it works. I will commit my changes to master as soon as they were tested.

@mkresin mkresin closed this Jun 24, 2017

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2017

Tested on nsa310b and goflexnet (booted initramfs image and tested internet connectivity usb and sata, used serial connection to do this), it's fine here. I can't test on nsa325 as it is in use, I doubt it matters much as it's not that different from the two I tested.

And yes I edited the makefile to make sure I was compiling the 4.9, and checked in the live systems by uname -r that I was indeed using the new kernel.

Can I ask why it's not switched on by default? Is it for the two router boards?

While doing a compile test I've spotted a new hw monitoring module:

Thanks for the heads up. I followed the discussion that lead to its mainlining http://forum.doozan.com/read.php?2,24655 , but then totally forgot about it, lol. :)

I'll probably be able to add the nsa320 then (it's basically a copycat of the 310 with some names changed and a thermal/fan controller over GPIO). That driver is used only on that device.

The nsa310 has a different thermal/fan controller that is already configured by my startup script.
The nsa325 has no fan control at all (fan is always on at max speed) even in stock firmware.

@p-wassi

This comment has been minimized.

Copy link
Contributor Author

commented Jun 28, 2017

Thanks, @mkresin for giving it a go and merging things to your staging tree.
I've just compiled everything and successfully tested it on a Seagate Dockstar;
everything seems to work fine (currently on 4.9.31).
Bootlog can be found at 1

@shifttymike

This comment has been minimized.

Copy link

commented Jun 30, 2017

Hi all. Here's the boot log after flashing from Linksys factory firmware (with factory u-boot)
https://pastebin.com/raw/b0EEXeGG
Unfortunately, it can't boot. Haven't had a chance to dig properly but the weird flash layout / recovery firmware might be causing problems.
Booting lede-kirkwood-linksys-viper-initramfs-uImage from RAM also doesn't appear to work:
https://pastebin.com/raw/AeuaqYi0
The console is dead - it echos what I type but I don't get a shell. There is also no networking, I set my IP to 192.168.1.5 and I can't reach or ping 192.168.1.1.
Flashing OpenWRT's current snapshot (bbe444f026fe06383b601b3a7ad33903914371beb1ee04414c583e3e4a3dbaf5) works fine. It is running 4.4.14 currently.

@shifttymike

This comment has been minimized.

Copy link

commented Jun 30, 2017

Ah. The stock u-boot doesn't have support for ubi, only mtd.
Unknown command 'ubi' - try 'help'

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2017

Ah. The stock u-boot doesn't have support for ubi, only mtd.

Nope, that isn't the issue. The bootloader has only to load and execute the Kernel. Which obviously works fine.

LEDE expects the rootfs in the partition named rootfs. If no partition with the name rootfs exists, it will use the partition named ubi.

The linksys boards have a dual kernel/rootfs layout, where the partitions are written alternating. According to 100-find_active_root.patch, U-Boot passes the parameter mangled_rootblock to the kernel, to indicate the current active kernel/rootfs pair. The 100-find_active_root.patch renames the partition to which is pointed to by mangled_rootblock to ubi.

But, This PR (and upstream) renamed:

  • rootfs1 to rootfs
  • rootfs2 to alt_rootfs

Means, we always have a partition named rootfs, which LEDE will use as rootfs partition. Regardless whether this partition is our actual rootfs (ubi) partition:

[ 0.882604] 0x000000000000-0x000000080000 : "u-boot"
[ 0.889325] 0x000000080000-0x0000000a0000 : "u_env"
[ 0.895387] 0x0000000a0000-0x0000000c0000 : "s_env"
[ 0.901372] 0x000000200000-0x0000004a0000 : "kernel"
[ 0.907484] 0x0000004a0000-0x000001c00000 : "rootfs"
[ 0.913705] mtd: device 4 (rootfs) set to be root filesystem
[ 0.919459] mtdsplit: no squashfs found in "rootfs"

^^^^

[ 0.924403] 0x000001c00000-0x000001ea0000 : "alt_kernel"
[ 0.930874] 0x000001ea0000-0x000003600000 : "ubi"
[ 0.936802] 0x000003600000-0x000008000000 : "syscfg"
[ 0.943193] 0x0000000c0000-0x000000200000 : "unused"

But I'm not sure if this is our only issue here. According to your bootlog (thanks a lot for this!) there is no parameter mangled_rootblock passed to the kernel:

[ 0.000000] Kernel command line:
console=ttyS0,115200 mtdparts=nand_mtd:512k(uboot)ro,128k@512k(u_env),128k@640k(s_env),26m@2m(kernel),26m@2m(rootfs)fs,26m@28m(alt_kernel),26m@28m(alt_rootfs)fs,74m@54m(syscfg)
root=/dev/mtdblock6
ro
rootfstype=jffs2
serial_number=12A10604258900
uuid=3122FBF9D1471F2606054876D68E3752
hw_version=RGWM-C4_0GA
device_mac=20:AA:4B:E5:D2:CF
factory_date=2012/04/23
wps_pin=15767097

No idea if it ever worked or I'm getting something wrong here.

Nevertheless, I will not be able to fix the linksys issues. I have zero to little knowledge about kirkwood. The fixes need to be contributed by someone else.

I've no idea why your network doesn't work. Would you please try to apply the changes to /etc/board.d/02_network from this PR? I don't have these changes in my staging tree. Could be that it is related to the DSA changes in the dts file.

The not working serial console is really a bummer. Debugging network issues without serial console is really challenging.

@p-wassi @bobafetthotmail @diizzyy The rootfs thingy is a blocker for merging even optional kernel 4.9 support. I'm not going to merge anything that will break support for a board. As usual, patches are welcome.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

@megal0maniac could you test with the images from current LEDE stable http://downloads.lede-project.org/releases/17.01.2/targets/kirkwood/generic/
and with current LEDE snapshot http://downloads.lede-project.org/snapshots/targets/kirkwood/generic/

Because there were quite a bit of changes between OpenWRT and LEDE until now (and you said you tested only my images and OpenWRT snapshot). Maybe it is already broken even in LEDE and this PR is not the culprit.

The rootfs thingy is a blocker for merging even optional kernel 4.9 support. I'm not going to merge anything that will break support for a board. As usual, patches are welcome.

I assume the build system can't keep these boards on kernel 4.4 while the other kirkwoods go to 4.9. (I think the only way would be to make a new target where I keep these two boards), and that you won't allow something like that for the sake of not bogging down other kirkwoods for the sake of 2 boards. Pretty please? :)

Really I woudn't like to have to keep my own fork, nor to buy hardware that is kinda crappy (both routers have marvell wifi and with current driver their switch is a dumb switch, no VLANs) and I have no real use for, just to try to fix it up so I can keep updated other stuff I care about.

@shifttymike

This comment has been minimized.

Copy link

commented Jul 3, 2017

could you test with the images from current LEDE stable and with current LEDE snapshot

Sure, I'll test when I get home

with current driver their switch is a dumb switch, no VLANs

Not true. OpenWRT can configure VLANs on the switch successfully, it is manageable with swconfig. I will check to see if the same is true for LEDE.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

Not true. OpenWRT can configure VLANs on the switch successfully

Hm, if switch works then I might have some use for it.

@shifttymike

This comment has been minimized.

Copy link

commented Jul 3, 2017

LEDE 17.01.2 works: https://pastebin.com/raw/zcwR34GD
LEDE snapshot (r4511-23da3fb) works too: https://pastebin.com/raw/Xrfxfded
Serial console, USB, switch and wireless all work. swconfig gives the same output as with OpenWrt

Output from swconfig:
https://pastebin.com/raw/JDGuNfBK

@shifttymike

This comment has been minimized.

Copy link

commented Jul 3, 2017

Nope, that isn't the issue. The bootloader has only to load and execute the Kernel. Which obviously works fine.

@mkresin derp. My bad. I was thinking about this on the way to work and realised that what I said was silly.
For what it's worth, every time I flashed I rebooted the router until the Linksys firmware booted and flashed from there to make sure that the kernel/rootfs pair stayed consistent.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

@megal0maniac thanks, that's a relief. So this PR is the culprit.

And in LEDE firmware that boots fine too there is no "mangled bootblock" either.

So it might just be fixable by renaming back the partitions rootfs1 and rootfs2 to what they were before so they don't confuse the "rootfs-finding-system" anymore.

Sounds easy enough, I'll try changing that manually and compiling a firmware for you to test.

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

@bobafetthotmail if you compile a firmware anyway, would you please patch the following changes into the E4200v2 / EA4500 dts.

  • enable the &eth1 node and set the values from the kernel 4.4 EA4500 patch
  • add the (console) bootargs from the kernel 4.4 EA4500 patch

Everything else should be more or less the same

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

I also edited the linxys.sh upgrade script to use the old partition names (and checked also the 02_network.sh to make sure it had eth6), so with these images sysupgrading should work.

If this works, then the ea3500's dts will need the same treatment.

This zip file contains all three images (initramfs, factory and sysupgrade) plus the dts patch I used for the EA4500, named "9999-main_code_fix.patch"

https://www.dropbox.com/s/z72gv0t3orhayj1/viper_images.zip?dl=0

@shifttymike

This comment has been minimized.

Copy link

commented Jul 3, 2017

Ta da! https://pastebin.com/raw/9ma7PGGE
It boots.
However, /etc/config/wireless does not exist and none of the wireless utilities (iw, wpa_supplicant etc.) are present. swconfig is also missing and networking doesn't appear to work - I can't communicate with the router using the LAN ports and it doesn't get an internet connection on the WAN port. The interfaces present don't really make sense.
Output of ifconfig -a : https://pastebin.com/raw/rgsNEHUc
USB works, I could test that at least.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

hmm, yeah from the build log it seems the mentioned packages were not added. Trying with a through clean and recompile.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

Ok it was a build system derp, the images in this zip have all utilities they should have, patch is still included in the zip file but I didn't change the source, only ironed out the build system derp.

https://www.dropbox.com/s/lq9o7htajkukzrj/viper-images-2.zip?dl=0

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2017

I've updated my staging tree with the changes provided by @bobafetthotmail. I don't see a reason why it should not work.

I've not added the (console) bootargs yet. It should work without.

@megal0maniac Would you please test my staging tree again. Beside the usual rootfs and networking thingy, I'm interested if the serial console works with the ramdisk image as well as the sysupgrade/factory image.

@bobafetthotmail I switched to 4.9 by default in my staging tree.

@shifttymike

This comment has been minimized.

Copy link

commented Jul 4, 2017

@bobafetthotmail Cool, it works! https://pastebin.com/raw/h1QaL127
Tested networking, wireless, USB, all good. ifconfig looks the same as before, which is a bit confusing - I don't get why the WAN port is eth1.2 and LAN is eth0.1. Nevertheless, it functions. This is without dts, correct?
@mkresin Is your staging tree the LEDE snapshot version? I'm only in a position to flash compiled binaries at the moment, I don't have a build machine running.

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

@mkresin Is your staging tree the LEDE snapshot version? I'm only in a position to flash compiled binaries at the moment, I don't have a build machine running.

No, my changes are not yet in the snapshot. As soon as they are tested I will commit my changes so that they are included in the snapshops. I've uploaded precompiled images to http://www.kresin.me/files/kirkwood/.

This is without dts, correct?

Yes, Albertos as well as my images are without the DSA based driver.

I don't get why the WAN port is eth1.2 and LAN is eth0.1

The switch is connected via two ports to the CPU. This way some kind of load balancing can be done. You can max out LAN without having a bottleneck on WAN.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

Tested networking, wireless, USB, all good.

@megal0maniac Thanks a lot for your time testing this. :)

Yes, Albertos as well as my images are without the DSA based driver.

@mkresin Is DSA driver better than current switchdev?
or, does it make any sense to migrate current switchdev boards to DSA where available (you mentioned also mvebu above, I assume that a script to migrate configs to DSA will work there too)?

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

We do not have a script yet to migrate the configs to the DSA syntax.

I know, I was asking if DSA was worth it because I am interested in writing that script.

@shifttymike

This comment has been minimized.

Copy link

commented Jul 4, 2017

@mkresin Flashed your binary, all looks good, everything appears to work: https://pastebin.com/raw/q5fUE8WT
Also saw that the in LuCI, the ports are more descriptively named so that's cool.
One weird thing, opkg is configured to fetch all but the core packages from arm_xscale. Is that intentional?

/etc/opkg/distfeeds.conf:
src/gz reboot_core http://downloads.lede-project.org/snapshots/targets/kirkwood/generic/packages src/gz reboot_base http://downloads.lede-project.org/snapshots/packages/arm_xscale/base src/gz reboot_luci http://downloads.lede-project.org/snapshots/packages/arm_xscale/luci src/gz reboot_packages http://downloads.lede-project.org/snapshots/packages/arm_xscale/packages src/gz reboot_routing http://downloads.lede-project.org/snapshots/packages/arm_xscale/routing src/gz reboot_telephony http://downloads.lede-project.org/snapshots/packages/arm_xscale/telephony

DSA would be great if it's a possibility, although I realise that it gets complicated when upgrading from the switchdev based solution.

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

Finally pushed, thanks a lot to all for the help.

Also saw that the in LuCI, the ports are more descriptively named so that's cool.

Not sure what you talking about. It should look the same as before. Would you please add a screenshot to give us a hint what you are talking about.

One weird thing, opkg is configured to fetch all but the core packages from arm_xscale. Is that intentional?

Yes that is intentional and not related to the kernel version switch. Only the base packages are build specific for kirkwood. All other packages are shared between all targets using an arm_xscale family CPU.

@bobafetthotmail

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

Hooray! :)

@shifttymike

This comment has been minimized.

Copy link

commented Jul 4, 2017

It should look the same as before

It probably does, I haven't run LEDE on this router before. I was comparing to OpenWrt where the ports are all labelled numerically, whereas LEDE has LAN and WAN, it makes things clearer.

Finally pushed

Yay! My pleasure, happy I could help :)

@mkresin

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2017

There one "bug" however, console (serial) stops working during bootup. The device boots fine so it's a minor issue...

FYI, @pepe2k tested kernel 4.9 on his iConnect and was not able to reproduce the freezing serial console. Seams to me everything is working.

@pepe2k

This comment has been minimized.

Copy link
Member

commented Jul 12, 2017

@diizzyy ^^^, tested with snapshots (LEDE and U-Boot) from today.

Cheers,
Piotr

@diizzyy

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2017

Great news :-)

@p-wassi p-wassi deleted the p-wassi:kirkwood_49 branch Jul 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.