Web UI to reboot to another partition (for Linksys/ZyXEL dual-partition routers) and to power off/power down

Community Builds, Projects & Packages
93

Probably is it quite different. That usage of /tmp/syscfg is specific to mvebu.
I have never even tried to look for that in ipq806x for EA8500, the only(?) Linksys dual-partition device there, as I have just the "normal" single-partition Netgear R7800.

EA8500 probably acts like a single-partition device regarding saving the config in sysupgrade.

AFAIK, /tmp/syscfg is mostly unused be LEDE, but just contains some stuff from OEM firmware. It is only used for storing config during sysupgrade flash. I am not sure if that is even mounted in ipq806x for that one Linksys device.

94

I'm pretty sure that this isn't just platform specific, but also depending on the actual firmware vendor.

As another ipq8065 example, I'll try to explain the ZyXEL NBG6817. This particular router has two flash chips, the bootloader is on a 4 MB SPI-NOR, kernel and rootfs (dual-partition) are on an additional 4 GB eMMC - for installing/ updating LEDE the SPI-NOR chip is never touched. The mtd partitionioning is interpreted slightly differently between the OEM ZyXEL firmware and LEDE.

OEM:

m25p80 spi5.0: found mx25u3235f, expected s25fl512s
m25p80 spi5.0: mx25u3235f (4096 Kbytes)
8 cmdlinepart partitions found on MTD device m25p80
Creating 8 MTD partitions on "m25p80":
0x000000000000-0x0000000c0000 : "SBL"
0x0000000c0000-0x000000100000 : "TZ"
0x000000100000-0x000000140000 : "RPM"
0x000000140000-0x0000001c0000 : "u-boot"
0x0000001c0000-0x0000001d0000 : "env"
0x0000001d0000-0x0000001e0000 : "ART"
0x0000001e0000-0x0000001f0000 : "dualflag"
0x0000001f0000-0x000000400000 : "reserved"

LEDE:

spi_qup 1a280000.spi: IN:block:16, fifo:64, OUT:block:16, fifo:64
m25p80 spi32766.0: mx25u3235f (4096 Kbytes)
13 qcom-smem partitions found on MTD device spi32766.0
Creating 13 MTD partitions on "spi32766.0":
0x000000000000-0x000000020000 : "0:SBL1"
0x000000020000-0x000000040000 : "0:MIBIB"
0x000000040000-0x000000060000 : "0:SBL2"
0x000000060000-0x0000000a0000 : "0:SBL3"
0x0000000a0000-0x0000000b0000 : "0:DDRCONFIG"
0x0000000b0000-0x0000000c0000 : "0:SSD"
0x0000000c0000-0x000000100000 : "0:TZ"
0x000000100000-0x000000140000 : "0:RPM"
0x000000140000-0x0000001c0000 : "0:APPSBL"
0x0000001c0000-0x0000001d0000 : "0:APPSBLENV"
0x0000001d0000-0x0000001e0000 : "0:ART"
0x0000001e0000-0x0000001f0000 : "0:DUAL_FLAG"
0x0000001f0000-0x000000400000 : "0:RESERVED"

The eMMC is partitioned like this:

Found valid GPT with protective MBR; using GPT.
Disk mmcblk0: 7471104 sectors, 3.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): XXX
Partition table holds up to 12 entries
First usable sector is 34, last usable sector is 7471070
Partitions will be aligned on 2-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34            8225   4.0 MiB     FFFF  rootfs_data
   2            8226           16417   4.0 MiB     FFFF  romd
   3           16418           18465   1024.0 KiB  FFFF  header
   4           18466           26657   4.0 MiB     FFFF  kernel
   5           26658          157729   64.0 MiB    FFFF  rootfs
   6          157730          159777   1024.0 KiB  FFFF  header_1
   7          159778          167969   4.0 MiB     FFFF  kernel_1
   8          167970          299041   64.0 MiB    FFFF  rootfs_1
   9          299042          823329   256.0 MiB   FFFF  bu1
  10          823330         7471069   3.2 GiB     FFFF  bu2

So far LEDE can only be installed to /dev/mmcblk0p4 (kernel) and /dev/mmcblk0p5 (rootfs), the OEM firmware alternates between mmcblk0p4/ mmcblk0p5 and mmcblk0p7/ mmcblk0p8. LEDE never touches mmcblk0p3 (header) or mmcblk0p6 (header_1), the OEM firmware stores the firmware version number "V1.00(ABCS.2)C0" there:

00000000  00 00 a7 74 01 32 f0 00  56 31 2e 30 30 28 41 42  |...t.2..V1.00(AB|
00000010  43 53 2e 32 29 43 30 00  ff ff ff ff ff ff ff ff  |CS.2)C0.........|
00000020  ff ff ff ff ff ff ff ff  00 00 d5 dc 4e 42 47 36  |............NBG6|
00000030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.............|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
...

fw_printenv (OEM):

addmtd=setenv bootargs ${bootargs} ${mtdparts}
addtty=setenv bootargs ${bootargs} console=ttyHSL1,${baudrate}n8
baudrate=115200
boot_mmc=run setmtdparts flashargs addtty addmtd;mmc read ${loadaddr} ${kernel_paddr} ${kernel_psize};bootm ${loadaddr}
boot_mmc_1=run setmtdparts flashargs_1 addtty addmtd;mmc read ${loadaddr} ${kernel1_paddr} ${kernel1_psize};bootm ${loadaddr}
boot_zld=sf probe&&sf read ${loadaddr} ${zld_paddr} ${zld_psize}&&bootm ${loadaddr}
bootcmd=run boot_mmc
bootcmd_1=run boot_mmc_1
bootdelay=3
bu1_paddr=0x00049022
bu1_psize=0x80000
bu2_paddr=0x000C9022
bu2_psize=0x656FBC
dualflag_paddr=0x1E0000
dualflag_psize=0x10000
eedualflag=sf probe; sf erase ${dualflag_paddr} +${dualflag_psize}
eenv=sf probe; sf erase ${env_paddr} +${env_psize}
eerfdat=sf probe; sf erase ${rfdat_paddr} +${rfdat_psize}
env_paddr=0x1C0000
env_psize=0x10000
eth1addr=0:3:7f:ba:db:2
ethact=eth1
flashargs=setenv bootargs board=NBG6817 root=/dev/mmcblk0p5 rootwait ${bootmode} ${zld_ver}
flashargs_1=setenv bootargs board=NBG6817 root=/dev/mmcblk0p8 rootwait ${bootmode} ${zld_ver}
hdr1_paddr=0x00026822
hdr1_psize=0x800
hdr_paddr=0x00004022
hdr_psize=0x800
hostname=NBG6817
img_prefix=nbg6817-
ipaddr=192.168.1.1
kernel1_paddr=0x00027022
kernel1_psize=0x2000
kernel_paddr=0x00004822
kernel_psize=0x2000
ldr_paddr=0x140000
ldr_psize=0x80000
loadaddr=0x44000000
lu=tftpboot ${loadaddr} ${dir}u-boot.mbn || setenv stdout serial && echo tftpboot download fail && exit 1;sf probe;sf erase ${ldr_paddr} +${ldr_psize} || setenv stdout serial && echo sf erase fail && exit 1;sf write ${fileaddr} ${ldr_paddr} ${filesize}
machid=136d
mtdids=nand1=m25p80
netretry=no
readonly=ro
reserved_paddr=0x1F0000
reserved_psize=0x210000
rfdat_paddr=0x1D0000
rfdat_psize=0x10000
rfs1_paddr=0x00029022
rfs1_psize=0x20000
rfs_paddr=0x00006822
rfs_psize=0x20000
rfsdat_paddr=0x00000022
rfsdat_psize=0x2000
romd_paddr=0x00002022
romd_psize=0x2000
serverip=192.168.1.99
setmtdparts=setenv mtdparts mtdparts=m25p80:0xC0000(SBL)ro,0x40000(TZ)ro,0x40000(RPM)ro,${ldr_psize}(u-boot)${readonly},${env_psize}(env)${readonly},${rfdat_psize}(ART)${readonly},${dualflag_psize}(dualflag),${reserved_psize}(reserved)
stderr=serial
stdin=serial
stdout=serial
uboot_env_ver=1.5
zld_paddr=0x1A4000
zld_psize=0x10000
serialnum=XXX
countrycode=E1
ethaddr=XXX

While it would be possible to change the bootcmd around, like on Linksys mvebu router, the vendor firmware doesn't change those settings - it uses the dualflag/ 0:DUAL_FLAG mtd partition instead. This 64 KB partition is completely initialized with 0xff, to toggle the boot order, only the very first byte of this partition is changed between 0x01 (boot from mmcblk0p7/ mmcblk0p8) or 0xff (boot from mmcblk0p4/ mmcblk0p5).

Boot from mmcblk0p4/ mmcblk0p5:

00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

Boot from mmcblk0p7/ mmcblk0p8:

00000000  01 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

The OEM firmware updater uses echo to toggle this settings, but printf is obviously safer (and works on both):
WARNING, the mtd number differs between ZyXEL OEM firmware (/dev/mtdblock6) and LEDE(/dev/mtdblock11)!

So assuming you're booted into the OEM firmware running from mmcblk0p7/ mmcblk0p8, all you need to do is

printf "\xff" >/dev/mtdblock6

in order to boot from LEDE on mmcblk0p4/ mmcblk0p5, on LEDE booted from there, you can simply reverse this

printf "\x01" >/dev/mtdblock11

and after rebooting you're back to the OEM firmware on mmcblk0p7/ mmcblk0p8.

1 Like
95

Added the linksys ea3500

{"Linksys EA3500", "linksys-audi", "mtd3", "mtd5", 32, "boot_part", 1, 2, "bootcmd", "run nandboot", "run altnandboot"},

1 Like
96

Thank you! Support added in build 24. I realize you've posted that line of code after you've tested it, but could you still please install build 24 and confirm it works?

97

Hello
Today i was surprised to see that on both partitions wrt1900acs V2, i run LEDE software with the same software version! In Advanced Reboot Partitions if I choose to boot in the first partition, where should normally be the software from linksys, it is the same version of LEDE software! I also tried with putty with fw_printenv boot_part, fw_setenv boot_part reboot partitions but return to the same software ..http://s.go.ro/8loxw5qh http://s.go.ro/98h0kjlo
Do I have a chance to rewrite the Linksys software from the LEDE interface?

98

Any chance that you might either read the whole thread or at least use forum search? Return to Linksys OEM has been questioned so many times...

In nutshell:

  • in Linksys dual-partition devices, you always flash the other partition, so that the current one stays as the fall-back option (in case the flash fails). That is done both by the Linksys OEM firmware and LEDE. If you have first used OEM to flash LEDE and then you have later flashed LEDE again from that, you now have LEDE on both partitions.
  • You can revert to Linksys OEM pretty easily. But LEDE uses a slightly different image checksum method, so the sysupgrade will not accept the Linksys image in LuCI GUI. But you can download the image with wget, curl, whatever to the router and then use "sysupgrade -F" from console to force flashing the image. See e.g.
    How to go back to stock firmware on wrt1900acs v2
    Need major help with going back to OEM firmware [Solved]
    WRT1200AC can not roll back to OEM fw
    you need to flash with manual sysupgrade from console using the force option -F, so download/copy the correct Linksys firmware to /tmp, ssh into the router, cd to /tmp and run sysupgrade -n -F linksysfirmware.img
1 Like
99

Hello again!

  1. In case if that on both partitions i use the LEDE software, this can affect the proper functioning of the router?
  2. There is the possibility to do a tutorial, where to explain all the steps in detail that we should follow to rewrite the image with Linksys software?
  3. If I can rewrite the image with the Linksys software, i will be able to get back to the partition with the LEDE software, without losing again the partition with soft linksys? Because i want to continue using the LEDE software!

I look forward to an answer
Thx

100

IMHO all of your questions have nothing to do with this package, so it's a completely wrong thread to ask these, but the question quoted above is definitely addressed in this package's README.

101

Hey

Was support for EA3500 added? I installed the luci-app-advanced-reboot (git-17.336.23170-d2dc..-23)form LuCI but it says: Warning: This system does not have two partitions!

So I assume it is an old build? Github also doesn't reflect support for EA3500

102

I'll create a PR for revision 24 sometime this week. Not sure if it will be back-ported to 17.01.4 tree tho, so in the mean time you can install the newer revision from my repo: https://stangri.github.io/openwrt-repo/

103

Thanks! It works now! Picture

104

Oh, sorry, looks like I never replied neither to your message nor to the follow-up with more technical information. Is LEDE still using only one partition on that router? If so, what would be the usefulness of this package on that router? If you use it to boot back to stock, you'll have no way to booting back to LEDE unless you reflash, right? I might be able to get some custom code for that specific box, but I'm not sure if it's going to be useful.

105

I've added support for booting LEDE from both partition sets in this pull request, which has been merged to LEDE master on November 6th 2017.

https://github.com/lede-project/source/pull/1476

The current sysupgrade support in LEDE however does not yet alternate between these partition sets, adding this would be trivial though (right now I do like to keep the OEM firmware for reference) - all information necessary to support this is known.

I've now published a simple example script (nbg6817-dualboot) to read- and modify the dualboot flag (and some related information) at

This is working on both LEDE and the ZyXEL OEM firmware, it can be copied as-is to the overlay and be executed from there. I've licensed it under the ISC license, which is compatible to BSD, GPL2/ GPL3.

The only missing bits and pieces for a 'perfect' representation in luci-app-advanced-reboot would be if LEDE could write the version header to header (/dev/mmcblk0p3) and header_1 (/dev/mmcblk0p6) as described in my previous post, but that's mostly cosmetic.

1 Like
106

I need your help -- where (partition and offset) the partition "label" (ie: LEDE vs Stock) and the kernel version are stored so I could read them with the dd? Ideally post the complete command and the output WHILE BOOTED TO LEDE.

107

ZyXEL OEM firmware, version "V1.00(ABCS.2)C0":

header (/dev/mmcblk0p3):

# cat /dev/mmcblk0p3 | hexdump -C | head -n 5
00000000  00 00 a7 74 01 32 f0 00  56 31 2e 30 30 28 41 42  |...t.2..V1.00(AB|
00000010  43 53 2e 32 29 43 30 00  ff ff ff ff ff ff ff ff  |CS.2)C0.........|
00000020  ff ff ff ff ff ff ff ff  00 00 d5 dc 4e 42 47 36  |............NBG6|
00000030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.............|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

# dd if=/dev/mmcblk0p3 bs=1 skip=8 count=16 2>/dev/null
V1.00(ABCS.2)C0

kernel (/dev/mmcblk0p4):

# cat /dev/mmcblk0p4 | hexdump -C | head -n 5
00000000  27 05 19 56 30 17 e6 cf  57 9b 19 4c 00 1c 6a 58  |'..V0...W..L..jX|
00000010  41 50 80 00 41 50 80 00  c4 29 7c 36 05 02 02 00  |AP..AP...)|6....|
00000020  4c 69 6e 75 78 2d 33 2e  34 2e 31 30 33 00 00 00  |Linux-3.4.103...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|

# dd if=/dev/mmcblk0p4 bs=1 skip=32 count=25 2>/dev/null
Linux-3.4.103

rootfs (/dev/mmcblk0p5):

<this contains rootfs, the OEM overlay is on /dev/mmcblk0p1 (rootfs_data)>

ZyXEL OEM firmware, version "V1.00(ABCS.5)C0":

header_1:

# cat /dev/mmcblk0p6 | hexdump -C | head -n 5
00000000  00 00 bf 94 01 46 d8 00  56 31 2e 30 30 28 41 42  |.....F..V1.00(AB|
00000010  43 53 2e 35 29 43 30 00  ff ff ff ff ff ff ff ff  |CS.5)C0.........|
00000020  ff ff ff ff ff ff ff ff  00 00 d6 5a 4e 42 47 36  |...........ZNBG6|
00000030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.............|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

# dd if=/dev/mmcblk0p6 bs=1 skip=8 count=16 2>/dev/null
V1.00(ABCS.5)C0

kernel_1:

# cat /dev/mmcblk0p7 | hexdump -C | head -n 5
00000000  27 05 19 56 6a 19 f0 c0  58 dc e4 a7 00 1c 56 20  |'..Vj...X.....V |
00000010  41 50 80 00 41 50 80 00  71 34 fe 9c 05 02 02 00  |AP..AP..q4......|
00000020  4c 69 6e 75 78 2d 33 2e  34 2e 31 30 33 00 00 00  |Linux-3.4.103...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|

# dd if=/dev/mmcblk0p7 bs=1 skip=32 count=25 2>/dev/null
Linux-3.4.103

rootfs_1 (/dev/mmcblk0p8):

<this contains rootfs, the OEM overlay is on /dev/mmcblk0p1 (rootfs_data)>

LEDE/ master:

header (/dev/mmcblk0p3):

not yet updated by LEDE, so whatever was previously left there by an OEM firmware

kernel (/dev/mmcblk0p4):

# cat /dev/mmcblk0p4 | hexdump -C | head -n 5
00000000  27 05 19 56 67 c0 a3 ba  5a 2b 05 67 00 1e e5 fe  |'..Vg...Z+.g....|
00000010  42 20 80 00 42 20 80 00  cf 2d f2 d2 05 02 02 00  |B ..B ...-......|
00000020  41 52 4d 20 4f 70 65 6e  57 72 74 20 4c 69 6e 75  |ARM OpenWrt Linu|
00000030  78 2d 34 2e 39 2e 36 37  00 00 00 00 00 00 00 00  |x-4.9.67........|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|

# dd if=/dev/mmcblk0p4 bs=1 skip=32 count=25 2>/dev/null
ARM OpenWrt Linux-4.9.67

rootfs (/dev/mmcblk0p5):

<this contains rootfs and overlay>

Difference between LEDE/ release (prior to rebranding back to OpenWrt):

$ wget -qO- https://downloads.lede-project.org/releases/17.01.4/targets/ipq806x/generic/lede-17.01.4-ipq806x-NBG6817-squashfs-mmcblk0p4-kernel.bin | hexdump -C | head -n 5
00000000  27 05 19 56 ec f1 4c e3  59 e6 41 ec 00 1c 71 81  |'..V..L.Y.A...q.|
00000010  42 20 80 00 42 20 80 00  15 fd a6 c5 05 02 02 00  |B ..B ..........|
00000020  41 52 4d 20 4c 45 44 45  20 4c 69 6e 75 78 2d 34  |ARM LEDE Linux-4|
00000030  2e 34 2e 39 32 00 00 00  00 00 00 00 00 00 00 00  |.4.92...........|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|

$ wget -qO- https://downloads.lede-project.org/releases/17.01.4/targets/ipq806x/generic/lede-17.01.4-ipq806x-NBG6817-squashfs-mmcblk0p4-kernel.bin | dd bs=1 skip=32 count=25 2>/dev/null
ARM LEDE Linux-4.4.92

and current LEDE master (post rebranding back to OpenWrt):

$ wget -qO- https://downloads.lede-project.org/snapshots/targets/ipq806x/generic/openwrt-ipq806x-NBG6817-squashfs-mmcblk0p4-kernel.bin | hexdump -C | head -n 5
00000000  27 05 19 56 d0 2f aa f9  5a 3d 41 53 00 1f 5a f6  |'..V./..Z=AS..Z.|
00000010  42 20 80 00 42 20 80 00  68 04 c4 25 05 02 02 00  |B ..B ..h..%....|
00000020  41 52 4d 20 4f 70 65 6e  57 72 74 20 4c 69 6e 75  |ARM OpenWrt Linu|
00000030  78 2d 34 2e 39 2e 37 30  00 00 00 00 00 00 00 00  |x-4.9.70........|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|

$ wget -qO- https://downloads.lede-project.org/snapshots/targets/ipq806x-NBG6817-squashfs-mmcblk0p4-kernel.bin | dd bs=1 skip=32 count=25 2>/dev/null
ARM OpenWrt Linux-4.9.70

Kernel and rootfs (and therefore label/ kernel version) are only stored on the eMMC (/dev/mmcblk0), which has a normal GPT partition table - accordingly the partitioning is identical between the OEM firmware and LEDE. Nothing firmware version specific ever touches the SPI-NOR, it's all contained within the eMMC.

What does differ is the partitioning of the SPI-NOR flash, this makes the numbering of the mtd partitions slightly volatile. Both LEDE and the OEM firmware only use the mtd label via find_mtd_part() from /lib/functions.sh; unfortunately this label also differs between OEM ("dualflag") and LEDE ("0:DUAL_FLAG"). This bootflag is the only data that 'ever' gets modified on the SPI-NOR flash.

I've detailed the partitioning for SPI-NOR and eMMC under LEDE and the OEM firmware as well.

1 Like
108

I've added a simple version decoder to my example script:

https://github.com/pkgadd/nbg6817/commit/4dc641c9c52feaed7e26792c835647e80435887b

Lede/ master:

# /tmp/nbg6817-dualboot --get-version /dev/mmcblk0p5
HEADER partition is located at "/dev/mmcblk0p3"
KERNEL partition is located at "/dev/mmcblk0p4"
ROOTFS partition is located at "/dev/mmcblk0p5"
 
FIRMWARE_VERSION="LEDE/ Openwrt <unknown revision>"
KERNEL_VERSION="ARM OpenWrt Linux-4.9.67"
UNAME_VERSION="4.9.67"

ZyXEL OEM Firmware, version V1.00(ABCS.5)C0:

# /tmp/nbg6817-dualboot --get-version /dev/mmcblk0p8
HEADER partition is located at "/dev/mmcblk0p6"
KERNEL partition is located at "/dev/mmcblk0p7"
ROOTFS partition is located at "/dev/mmcblk0p8"
 
FIRMWARE_VERSION="V1.00(ABCS.5)C0"
KERNEL_VERSION="Linux-3.4.103"
UNAME_VERSION="3.4.103"
1 Like
109

The NBG6817 doesn't have an equivalent to the syscfg partition, but it can be powered off by the kernel (/sbin/poweroff).

110

Thanks to tremendous amount of support and testing from @slh, support for ZyXEL NBG6817 has been added to the build 25 which is available in my repo. I've also sent a PR for the latest changes to be back-ported to current release tree.

111

Great application I have it installed on a EA8500
I also own a EA9500 would it be possible to get support for this device as well?

Would you need any input from me? Log files or anything?

Thanks

1 Like
112

What must I do to make dual-boot work on x86?
I have LEDE installed on a SSD with dos partion table and GRUB in /dev/sda1 and root in /dev/sda2. There is a lot of free space after sda2.