Help required to fix bug: porting from legacy to generic build form (WNR2000v3, 4/32 device)

@jow, apologies to you and especially to @mhoxjwwi.

Perhaps I should make another thread. I've identified a few devices at this time with 4MB Flash, upon which 18.06 is not installing ("too large"). Perhaps populating such a table in another thread will be more productive, as to assist developers and purchasers of routers in not wasting time on certain devices and/or targets with devices containing <= 4 MB Flash.

I write it again:
The build server/toolset create images for devices that are then later too big to work as expected.
I have been told that this have been fixed in the the new build code process.
Could some dev please move the device to the modern build process so that we dont have a non working image as a "stable" release? This is an issue about the WNR2000v3 since 15.05.1 . Could some dev help fixing it finally?

One of the key, unanswered (and perhaps unasked) questions is "How close are you?"

What is the size of the image that you are generating now?

If the difference is much more than tens of kilobytes, I would think it unlikely that a change of how the image is constructed from the individual components would save enough to have your device functional.

Have you already tried removing everything that you don't absolutely need from your build configuration? I would be surprised if anything but a very skeletal configuration would fit into 4 MB of flash.

Working images:
https://archive.openwrt.org/barrier_breaker/14.07/ar71xx/generic/openwrt-ar71xx-generic-wnr2000v3-squashfs-sysupgrade.bin
https://archive.openwrt.org/chaos_calmer/15.05/ar71xx/generic/openwrt-15.05-ar71xx-generic-wnr2000v3-squashfs-sysupgrade.bin
https://downloads.openwrt.org/snapshots/targets/ar71xx/tiny/openwrt-ar71xx-tiny-wnr2000v3-squashfs-sysupgrade.bin

Non working images:
https://archive.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/openwrt-15.05.1-ar71xx-generic-wnr2000v3-squashfs-sysupgrade.bin
https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/lede-17.01.4-ar71xx-generic-wnr2000v3-squashfs-sysupgrade.bin

On the 17.01.4 i got as written in first post:
" [ 24.443074] jffs2: Too few erase blocks (4)"

I am not a file-system expert. I think that this message just mean, that 4 blocks are required beeing available, but less then 4 blocks are available. I think this can be build into the build-toold to know that based on the information how much space the device have, it should not build non-working images. And its known that the device have 3712k of space for the firmware image.

A advanced user told me, that this is been already solved in the new build process and it already proves, that it does not build non-working images. So please port this device from legacy to the new generic build process so that there are no non-working images beeing build.

thanks

Would you also post the output of

cat /proc/mtd

since the flash layout doesn't appear to be on the device's OpenWRT page?

For anyone interested

jeff@ubuntu:~/_tmp$ binwalk lede-17.01.4-ar71xx-generic-wnr2000v3-squashfs-sysupgrade.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
64            0x40            Squashfs filesystem, big endian, version 3.0, size: 1268809 bytes, 3 inodes, blocksize: 65536 bytes, created: 2017-10-17 17:46:20
1270848       0x136440        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2219100 bytes, 1022 inodes, blocksize: 262144 bytes, created: 2017-10-17 17:46:20

jeff, thanks a lot for looking into the issue.

here the output of a working(saves its configuration), recent prebuild official tiny snapshot:

Serial (wnr2000v3 have presoldered connectors):

[    0.872182] m25p80 spi0.0: found mx25l3205d, expected m25p80
[    0.878608] m25p80 spi0.0: mx25l3205d (4096 Kbytes)
[    0.883624] 4 cmdlinepart partitions found on MTD device spi0.0
[    0.889570] Creating 4 MTD partitions on "spi0.0":
[    0.894441] 0x000000000000-0x000000040000 : "u-boot"
[    0.901666] 0x000000040000-0x000000050000 : "u-boot-env"
[    0.909331] 0x000000050000-0x0000003f0000 : "firmware"
[    0.919890] 2 netgear-fw partitions found on MTD device firmware
[    0.926028] 0x000000050000-0x0000001b7440 : "kernel"
[    0.933240] 0x0000001b7440-0x0000003f0000 : "rootfs"
[    0.940713] mtd: device 4 (rootfs) set to be root filesystem
[    0.946454] 1 squashfs-split partitions found on MTD device rootfs
[    0.952720] 0x0000003a0000-0x0000003f0000 : "rootfs_data"
[    0.960662] 0x0000003f0000-0x000000400000 : "art"

log in on serial terminal by pressing enter:

 cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 003a0000 00010000 "firmware"
mtd3: 00167440 00010000 "kernel"
mtd4: 00238bc0 00010000 "rootfs"
mtd5: 00050000 00010000 "rootfs_data"
mtd6: 00010000 00010000 "art"

At least as I recall the general OpenWRT layouts, it looks like you've got

  • mtd3 for kernel -- 1,471,552 > 1,268,809
  • mtd4 for /root -- 2,329,536 > 2,219,100
  • mtd5 for /overlay -- 327,680 "available"

It doesn't look like the image is "too big", at least as far as the space you have available.

Your erase-block size is 65,536 so there really isn't enough space to manage a file system (jffs2 for /overlay) configured in that way (4 * 65,536 = 327,680)

The WNDR3700 you linked is an 8M device

  IMAGE_SIZE := 7680k
  MTDPARTS := spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,7680k(firmware),64k(art)ro

Changing the "partitioning" isn't going to magically make more space appear in your 4M device

wnr2000v3_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,3712k(firmware),64k(art)ro

I think you're going to need to strip out at least 150 kB of "apps" from your image, if not more. I'd start by getting rid of LuCI and uhttpd and see if that gets you a runnable image.

As i wrote, there are runnable images. I linked those above.

Of course i wont get "magically" space when linking to the WNDR3700. I linked to the WNDR3700 because its configuration in the sourcecode looked nice.

I really dont understand if i am not clear enough here about the request for going from legacy to generic to stop the build system of building images that are too big for the device.
Thanks for your advice that i have to get rid of luci and uhttpd if i want a runnable image - but thats what i already have with the official snapshot builds.

I can just repeat myself: Can someone please move the device from legacy to generic so that no more non-working images are being build by the build-server thanks to the size-check an advanced user told me about?

Whether the build system stops or not, you still need another erase block (64k of free space) to get the jffs2 filesystem to mount, and perhaps one more after that once you write anything to it. Even if the work you requested is done, you need at least another 64-128k reduction of your rom image.

        if (c->flash_size < 5*c->sector_size) {
                pr_err("Too few erase blocks (%d)\n",
                       c->flash_size / c->sector_size);
                return -EINVAL;
        }

You can always check the size of your image on your build system with the command I used above (likely need to install the package on your OS as I don't think it is a "default" one for most distros):

$ binwalk lede-17.01.4-ar71xx-generic-wnr2000v3-squashfs-sysupgrade.bin 
1 Like

on new ath79 tl-wr841n-v9 target I can have luci with squashfs block size set to 1024 and no problems till now, that's why I told you to try that

2 Likes

@lucize
building now with 1024 instead of the preconfigured 256.

But the build process should still be fixed to not create non-working images.

The ar71xx "architecture" is on its last legs, with significant effort going into the forward-looking ath79 build tree for the same CPUs (allowing newer kernels to be used, among other things). "Fixing" the build system for a soon-to-be-deprecated architecture that does build valid images is unlikely to be a priority, unless you or someone you know are personally motivated to take on the work yourself.

1 Like

@mhoxjwwi Is there a report on the bug tracker about this? If not, why not file one?

1 Like

@Borromini

Take a look at the first forum post. The link to the bug is/was: https://bugs.openwrt.org/index.php?do=details&task_id=672&string=WNR2000

I highlighted it on the ML a few minutes ago.

@mhoxjwwi Now's your chance:

http://lists.infradead.org/pipermail/openwrt-devel/2018-May/012554.html

The device is working fine. Just fix the BUILD SYSTEM! Wtf, why would you want to remove the support for the device? Its working fine without Luci and there are the perfectly fine working snapshot images: https://downloads.openwrt.org/snapshots/targets/ar71xx/tiny/openwrt-ar71xx-tiny-wnr2000v3-squashfs-sysupgrade.bin

I am reporting here an issue that the build system buids too large images for a device and then you want to thank me for the report of the error by dropping support for my device?
The build system should calculate the max possible size and if a build image is bigger then that, then dont upload non-working-too-big images as stable releases to the servers.

No, what is happening is the following:

  • you reported the issue
  • no developer seems to be able to or care about fixing this device, as it's not just moving it to the tiny target but also migrating it to the new target using dts files instead of the old system, as the whole ar71xx is going to be deprecated in years. And this device is on its last legs as far as ram and flash, so it won't last much longer anyway.
  • the choice becomes either shipping a broken firmware upgrade or dropping support for this device

Note that deleting a device from a project managed with modern source versioning systems (like git) isn't permanent, anyone can just check the source code at the moment in time before someone deleted your device and all things will be exactly as they were, which can be useful if someone interested in porting the device over to fix it shows up.

1 Like

It would stop having fully fine working snapshot images with all security relevant things like build in WPA2-KRACK fix and so on. Every user of this device would then have to know how to use build system, how to use git to revert things, ...
This would be insane additional amount of work for users who can now just download a file and install it.

Download a file without luci and without much space to install anything at all, yeah. I quite frankly don't get why the WNR2000 series of routers has so much fans out there, I've also helped people in a PR (that was never merged) to build a firmware for their WNDR2000v4 I think and many people were interested.

My devices with 4mb flash can only be used with firmware images created with the Image Builder or from source, unless you're fine with ssh only and base system only, which is quite meh imho.

But if you insist that it's good to keep the snapshot building, you can ask them (on the mailing list possibly) to drop this device only from the release branch, so it won't have a 18.06 firmware, but the snapshots will still be built for it.