The way the Shield is setup, it should be treated as there separate devices in one shell, because of the way you have to pass kernel cmdline arguments to mount the storage.  Their contention is, the shield is a single device and only needs a single image.  They point to other "dual boot" routers, which are dual boot, but not in the same way the Shield is.. They have a single NAND flash kernel and are able to select which gets booted storage wise.  By the time the shield boots, it's to late.

The initramfs image would work in any slot, because it's not reliant on the eMMC device for storage..  The sysupgrade images contain the target'ed kernel (I pass on root=/dev/mmcblk1pX rootfs=squashfs,f2fs,ext4 rootwait to the kernel at compile, one for each mode so I can change the mmcblk1p2,3,4 etc).  So, a single image would technically work  in any slot depending on what you named the file (ItusrouterImage, ItusgatewayImage, ItusbridgeImage), but it would ONLY USE /dev/mmcblk1p2 for storage, because that's what hardcoded into the kernel cmdline.

That's fine, but you no longer have any use of the front-panel switch.  You also lose out on the 1.7Gb of storage left from /dev/mmcblk1p3 and /dev/mmcblk1p4.  You could re-partition it, but there is no way I'm automating it or hand-holding here for it.  Bad things can happen when you monkey with partition tables..

What I've done is put in a PR for the single device image that only uses the Router slot.  This will get the device mainlined at least, and for those who don't care, it'll give them an legit official device.  This way, at least something is offered.

For the rest, like me, who don't like this solution, I'll also continue with my own repo that'll support the other modes.  I think that really would be the best way to ensure everyone gets at least some support.

Gnomad wrote

I'm not quite following why it would kill the mode switch.. Aren't we
talking just getting them to build
1 the initram image
2 upgrade image
3 packages?

So, even if they will only build for one mode, can't we still supplement?

If that's not a goer, I reckon just try Github Actions to automate it
unofficially..

On Wed, 22 Jul 2020, 9:06 pm Grommish [via Itus Networks Owners Forum], <
[hidden email]> wrote:

> Well.. in talking with some of the OpenWrt dev team, they want to concat
> three images into one in order to be considered for inclusion into the
> mainline.
>
> This means making the mode switch irrelevant and having only a single
> image-mode.  At that point, we either lose out on 1.7Gb of space by staying
> with the 850Mb partition for the image, or repartition..
>
> Thoughts?  Is being included in the mainline worth it?  I can see their
> point, but without a lot of work I'm not willing to undertake right now, I
> don't know how to create a single image that will work in all three spots
> without far too much hassle.
> Running Itus Shield v2 Firmware
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://itus.accessinnov.com/FIRMWARE-Itus-Shield-v2-tp2014p2115.html
> To unsubscribe from [FIRMWARE] Itus Shield v2, click here
> < .
> NAML
> <http://itus.accessinnov.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

Running Itus Shield v2 Firmware