OpenWrt's stance on breaking vendor compatibility

For Developers
1

Hey all,

First some background, I have an XGS1010-12, which is hardware-wise (lack of a reset-button) completly identical to the XGS1210-12. Software, is a different matter; the XGS1010-12 is an unmanaged switch, and in software, makes use of pretty much the entire RTL930x SDK defaults. This also means the stock partition layout, is one with 2 firmware banks (each about 7MiB). Except for mtd0 (u-boot binary) and mtd5 (kernel + initramfs) all mtd's are all completly empty. No data is stored in them, so yes, the secondary firmware slot is empty :stuck_out_tongue:

The XGS1210-12 however, is webmanaged, and has a single firmware bank configured, that's about 15MiB.

Now of course, I can just install the XGS1210-12 vendor/openwrt firmware, and would have a big partition, and we just treat the XGS1010-12 as a XGS1210-12, no problem right.

But my real question, is of course more then this bit of background :slight_smile: To make better use of this switch (at the cost of loss of the second firmware bank support) is to use an 'openwrt optimized partitioning scheme' e.g. do a partition layout that that is sane, in this example, it would be simply spanning both firmware banks, but more things could be envisioned, that's a bit besides the point for now.

In software this could be easy still, we have 2 targets -vendor or -stock and openwrt, mostly affecting partition layout I can imagine, but sometimes this would also require 'migration' for users. E.g. boot initramfs, make backup! (you should do this always right) and then move your calibration/factory data from a to b (though this usually would only work on targets that also do U-Boot changes ...).

Anyway, a lot of background/thoughts from my end; what is the generally OpenWRT stance here? I get that we want to offer 'the most easy path from stock' but we don't want to hamper the devices possiblities/future because the vendor did something ... stupid?

2

Having spent some time thinking about this, specifically with regards to the vendor compatibility partition layout; obviously, we want to keep the uboot, uboot environment and calibration partitions in place, as managing those would be hard/tricky. Uboot is generally not replaced etc.

However, everything else should be fair game, in that, if one is running openwrt, and they wish to go back to the oem binary, they already either have to flash using (oem) uboot; or, if lucky use some trick to flash the vendor image (if one kept an mtd dump, that of course helps). Since the devicetree is generally responsible for defining the partition layout, going back to vendor, returns one to the vendor partition layout.

So then the question remains open is, what about 'dual firmware support'. Well dropping support for that (openwrt doesnt really support it) and with serial/tftp/uboot ways need to install the firmware anyway, it doesn't really matter that one can switch active partitions ... just runtime vs flashtime really ...

3

IMHO the XGS1010-12 is special enough for you to do whatever you find most practical from an OpenWrt user perspective.

I could be wrong, but I don't think there are any other examples of an OpenWrt supported device which is completely unmanaged when running OEM firmware. One implication of the unmanaged part is that there is no way to switch active image or install/upgrade OEM firmware without either using OpenWrt or the bootloader console. So you do "keep compability" as long as you provide a documented way to switch back to OEM from OpenWrt.. And you can do that regardless of how you use the two system partitions in OpenWrt.

"dual-boot" with OEM and OpenWrt installed in separate partitions doesn't make much sense in this setting since the user would need console anyway to switch away from OEM. You could use one partition as an OEM backup. But that's a rather "expensive" backup storage which would be much better used as a larger OpenWrt rootfs.

In any case, if you do want to leave the dual partiitions in place, then I think it makes more sense to install OpenWrt in the empty partition and leave the OEM one untouched. This way there is no need for the end user to ever mess with copying the OEM image around. And going back to OEM will be as simple as running an fw_setsys command in OpenWrt.

It's true that OpenWrt currently doesn't support switching between the partitions, but you are free to choose which of the two OpenWrt will be using.

4

Yeah, I was thinking the same, but in our particular example, it's a little more subtle. For example the OEM firmware keeps a 'log' and 'cfg' partition around, costing 1MiB each, so that's quite a bit of flash. Why would I want to keep those around? If we go back to OEM, yes, factory reset; but how unacceptable is that?

So my question stands, what is OpenWRT stance on this? If you go back, do you need to keep all your application configs, keys, passwords etc as well? I know for most other systems we certainly don't. If I do so with an Accesspoint, it's one or the other; and going back (if even possible) you've lost all your settings also. (bar-calibration data, I think we do our best to keep that).

5

I spent weeks wasting time on the early XGS1250-12 port because OpenWrt just claimed the remainder of the flash, including that log partition.

Wipe it, and see what happens I'd say. You got the chops to fix it :smiling_face:.

6

haha, I did :stuck_out_tongue: I made openwrt start on mtd3 (so wiping jffs[12] as well).

For my device (XGS1010-12) I have no data and slightly different (no tailing log) partition. And since it's all empty and unused, it doesn't affect me. But again, I'm after the overal stance. Personally, i say 'make an openwrt optimzied partition layout, and dont' care about OEM, as long as you can go back without breaking stuff (nuking factory/calbiration data)

1 Like
7

That's the baseline from what I gathered, as long as you can revert to stock without any kind of esoteric procedures that are far beyond what a normal end user can perform.

8

how to measure that :slight_smile: end-users that install openwrt tend to be more skilled; if you are talking about 'my mom' she just needs to be able to click a button, right? But I wonder what facilities openwrt generally has in place to go back to stock. In the end; nearly everything is possible...

But! @Borromini I like that approach, don't worry to much about OEM.

Next question; that's not just about partition layout. LED behavior. Those might differ from OpenWRT if they make (much) more sense; still fair game?

9

Well, some historical examples:

  • Recent Linksys E8450 / Belkin RT3200 is a recent popular router, where you have the alternative to continue with using stupid OEM partitioning for OpenWrt, or you can switch to the ubi based partitioning and a modernised bootloader. The ubi variant is tailored by @daniel who maintains the conversion build. As the conversion tool (special firmware) requires steps that are currently impossible with the default build system, the compilation scripts have not been merged to the OpenWrt repo. You can't easily return to OEM, as the whole bootloader has been changed. But still, the ubi variant is more popular.

  • A non-destructive example is R7800 (and some close ipq806x relatives), where the firmware partition was enlarged by taking space from six OEM extra partitions. For that purpose, I tested that the OEM firmware will re-create those extra partitions if they are missing. See

10

Thanks @hnyman that sounds very interesting. I think in time, openwrt will be very popular on these switches. Re-building U-Boot might be needed though; if we want to maximize (and improve) U-boot. As right now, the bootlocation seems to be hard-coded :frowning: e.g. bootm $flashaddress works; but of course, there's no bootcmd and right now, it always boots its custom boota command. I'll have to check the u-boot code if they just ignore the bootcmd and if set it is used, or actively removed it...

nmv, printenv answers all:

bootcmd=boota

So not an issue :slight_smile:

11

I believe OpenWrt policy here is to mimic OEM behaviour to the extent possible.

12

Even when openwrt has better ideas generally, and the vendor just dumb lazy things?

13

Actually, I just learned (only ma ancient DIR-825 that runs elsewhere), that also there, some re-adjustment is possible with a -fat binary. While I haven't explored it; it least it indicates to me, that the general openwrt stance, is to allow flexibiltiy.