[Solved] Zyxel NBG6817 flashing from OEM

Wow! Thanks for the great work! I will try it out on my NBG6817 aswell.

I've read the mailing list. Just a few thoughts, no big deal: afaik, the stock firmware allows either flashing the same version or a higher version. I think going with RAS_VERSION := "V1.00(ABCS.9)C0" RAS_VERSION := "V1.00(ABCS.8)C0" would be a wiser solution, as this will also prevent people from flashing from a possible and untested ABCS.9. Once ABCS.9 has been officially released and confirmed not bricking your device after flashing the make-ras image, RAS_VERSION could be increased.

Many, many thanks to anyone involved! Incredible work!

//Edit: I meant ABCS.8, not ABCS.9.

Flashing via tftp doesn't do any version checks, so reverting to stock firmware is unaffected by an inflated OpenWrt version number. Using the expected next OEM version would be a problem for OpenWrt releases, as it's likely to be reached by OEM during the life cycle of an OpenWrt release.

I've added quite a few new features to nbg6817-dualboot and refactored the usage description to make it a bit easier to read (all existing parameters remain unchanged). Combined with the factory images in master, this should be mostly feature complete.

I've flashed OpenWRT from Zyxel ABCS.8 Web-Interface. Worked flawless! Thanks for all the efforts, this is really helpful! A bit sad, it didn't make it into OpenWRT 18.06.1. However you can easily use the SNAPSHOT release for easy installation and install 18.06.1 via sysupgrade afterwards.

Please note, SNAPSHOT releases don't have a GUI; you will need to SSH, wget the 18.06.1 image and do sysupgrade via cli, but I think this is still safer / less of a hassle than the original method. And from 19.01 onwards, this will be child's play.

Very pleased by 18.06.1, incredible how much this project improved in such a short time.

After 12 days of flawless uptime, my NBG6817 randomly rebooted today. My R7800, which I setup at the same time, still runs. NBG6817 is facing WAN though, therefore handles PPPoE and has a few extras installed, like SQM, UPnP and DDNS. I have OpenWRT 18.06.1 installed on both devices.

Unfortunately, kernel logs are per default written to /tmp (or am I wrong?), so I couldn't reveal anything afterwards. I will setup logging to syslog server, so I will have proper kernel logs next time.

Anyone else experienced crashes?

There is NBG6817: OpenWrt rebooting constantly but mine is stable.

1 Like

Just to extend my previous remark, while testing flow-offloading I did notice several spontaneous reboots (also on lantiq, not just the nbg6817) - since disabling flow-offloading the nbg6817 has been rock stable for me. As I don't really need flow-offloading for my maximum WAN speed, I didn't investigate this any further and just kept it disabled (as per default).

Oh okay. I assumed it was a non-issue, as OP didn't had flow-offload enabled. I have disabled it now. I'll report back.

I had 20 days uptime, until our oven malfunctioned and caused a power outtage. However, I had no issues within those 20 days and the Zyxel happily runs again. I think disabling flow-offload indeed fixed my issue. Thanks!

1 Like

Thanks for confirming my hunch.

@slh quick question for you.

polishing the rt2600ac stuff off here... before delving in for a day or two to polish....

  1. Is there a shared "target" script ( target -> basefiles -> bin -> ? ) the BOOTTOGGLE can be done in ( or should there be )?
    -will it help if the uboot variables have commonality

  2. Likewise, with advanced reboot ( does it hook in somewhere or is it's config static )?

Cheers!

( got factory today, very happy indeed :slight_smile: )

Almost everything you're looking for will be under:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ipq806x;hb=HEAD

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/image/Makefile;hb=HEAD for the image generation

https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ipq806x/base-files/etc/board.d;hb=HEAD 01_leds and 02_network for the preconfiguration

https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ipq806x/base-files/lib/upgrade;hb=HEAD for adding the necessary hooks for proper sysupgrade support

https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ipq806x/files-4.14/arch/arm/boot/dts;hb=HEAD for the device specific dts file

you 'usually' don't need to think too much about uboot, defining the ubootenv partition (APPSBLENV) at most, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-envtools/files/ipq806x;hb=HEAD

For luci-app-advanced-reboot support, you'll need to hook your device up into https://github.com/openwrt/luci/blob/master/applications/luci-app-advanced-reboot/luasrc/controller/advanced_reboot.lua and talk to @stangri. I don't know how similar the rt2600ac handles booting, but you may find some additional help in https://github.com/pkgadd/nbg6817 to get started.

As I've been loosely following your discussions about rt2600ac support, it shouldn't be too difficult to support it properly.

I'd suggest to start on a device page in the wiki early (nothing sucks more than writing it all up months after doing it), it will need its own device page though (aside from using eMMC, the rt2600ac doesn't have that much in common with the nbg6817, with quite considerable differences). A dedicated forum thread might also help (I'll keep an eye on it and respond, if I can lend a hand).

2 Likes

Thanks dude, done about 90% of that.... but it is really! useful for future readers that's for sure. Gonna leave the leds and external slot for someone else....

As it relevant here.... a teency bit.....;

rt2600ac)

no dual - emmc______________
[16MB]   ext2   "kernel+rd"   < wrtkernel
[16MB]   ext2   "kernel+rd"     untouched
[1.2G]   ext4   "synorootfs"    untouched
[2G]     ext4   "space/data"  < wrtrootfs
[800MB]  ext4    syno-osrecovery   n/a

uboot needed
mtd9 0x0 0x40000 0x10000
APPSBL/package def only found two days ago!

Very, very x86 like. Most install functions are cp and tar.

Will get in touch with @stangri cause my gut is telling me there is some overlap in these "higher level" devices when it comes to install/recovery/bootselection etc.

Hi everyone, sorry for my pool english,

I break the emmc partition by fdisk, i tried to flash ras.bin from tftp, but it's not working...
So I think the gpt partition must be restored at first, and I found a command ATUG from serial port

ATUG upgrade GPT partition table on GMMC (gpt_main1.bin, gpt_backup1.bin)

but where I can find the gpt_main1.bin?

Here is all the command under U-boot

ATBT    x         bnock0 wrmteenable (1=enable, 0=disable)
ATWM    x         set MAC"address$inworking buffer
ATEN    x[,y]     set BootExtension Debwg Flag ,y=assword)
ATSE    x         show the seed of password ggnerator
AWZ     x[,y,z]   write ZyXEL MAC addr, Country code, HTP"flag
ATCB          copy from FLASH to working buffer
ATSB      "     ! save working buffer to FLASH
ATSH              dump manufacturer!related data in ROM
ATCO    x         set country code in working!buffer
ATFL    x         set HTP flag in working buffer
ATSN    x  ! $    set serial number in FLASH ROM
ATGU              go bcck to!mester loader
ATCL              erase U-Boot environment, sjould ce$reboot
ATCR              erase rootfs_data partition
ATRV    [x,y-z,u]RAM read/write test (x=level, y=start addr, z=end adfr, u=iteraions)
ATGO              boot up whole system
ATUR    x  "     !utgrde RAS image (filename)
ATUB    x         upgrade ZLD kmage )fmleame)
ATUG              upgrade GPT partition table on GMMC (gpt_min1.bin, gpt_backup1.bin)
ATUD    x         upgrade ROOD image$(filename)
ATCD              erase RomD partition
ATLD    x.[y]  ! $load file X to memory address Y via TFTP
ATMB    [x,y]   " upgrade firmware image by multiboot
ATDU    x[,y]     dump memor{ or regmsters
ATWW    x,y,z     set memory or registers(x=address. y=vamue, z=len)
ATER    x,y       erase flash from block X to block Y
ATRF    x,y[,z]   read/dump flash to ram/console(x=flash offset, y=len,z=ram address)
ATWF    x,y,z     write data from RAM to flasi(|=RM address, y=flash offset, z=len)
ATDS    x,y       duop data of pare area in page Y of block X
ATSWF   x         switch flash$tye for command ATER,ATRF,ATWF(x=0(NOR), 1(NAND))
ATCOP   x,y-z$   compare two memory space x and y with length is z
CTLED   [x,y]     set LED (x=led no, y=blink mode)
ATPIO   x[,y[,z]_ set GPMO (x={d|s|w|r}, y=pio num, z=write data)

The easiest option might be to boot an initramfs image and re-creating the partition table.

Thank you for your advice,
but I can't find any command under U-boot which support boot from RAM or TFTP.
the ATGO for NBG6817 does not support parameter..

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}

so tftpboot should be available

Thanks, where can I run the tftpboot? On my ubuntu server(installed tftp service) or NBG6817's serial port interface?
It seems only these AT* command are supported under serial port interface..

Hello everyone and sorry for my English and poor understanding of OpenWrt. I installed the last stable release of OpenWrt 18.06.2 and I can not understand why only 51.14 MB are available for installation of programs. Can anyone explain me how to access the 4GB eMMC?

That value is correct, please see https://openwrt.org/toh/zyxel/nbg6817#flash_layout for details.