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

I have a device here that is based on the old build form. I got from a advacend openwrt user the info, that the build process then dont check if the image is too big in the legacy build format.

Could a dev make a patch that would move the device from legacy to generic? I would then test the patch and confirm if its working fine. Then the dev could merge it upstream.

The device: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/image/legacy.mk#L269

I think at the end it should look something like that: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/image/generic.mk#L568

If that is not done, then the 2018.6 release of openwrt would have a broken/non working image like the recent 17.01.4 image for the linked device.

Recent problem from serial log with 17.01.4:
[ 24.443074] jffs2: Too few erase blocks (4)

That results in not saving the configuration. When you power off the device, all settings are gone.

If you install the latest snapshot (thats without luci), the same place looks like this:

[   24.391189] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[   24.398114] jffs2_build_filesystem(): unlocking the mtd device... [   24.404243] done.
[   24.406179] jffs2_build_filesystem(): erasing all blocks after the end marker... [   26.920309] done.
[   26.922319] jffs2: notice: (986) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.

Then also saving of the configuration works.

Bugs reported about that:


https://bugs.openwrt.org/index.php?do=details&task_id=672
https://dev.archive.openwrt.org/ticket/22172

Thanks

not enough space on device for all packages you selected, you can try increasing squashfs block size to 1024 from image settings and see how it goes

This thread is really more about "please help moving from legacy to the recent build form".

@lucize Could you help with that?

@mhoxjwwi,

Please see this unanswered questions in that thread:

Earlier in that topic, @slh surmised and gave reason for asking:

Please identify your device and confirm that it has more than 4MB flash.

See:
https://openwrt.org/supported_devices/432_warning

lleachii, you wrote, that i should see the unanswered questions in the thread and quoted the question if the TP-Link TL-WA855RE have really more then 4MB of flash. Why should i care about the amount of flash other devices have? Dont understand that.

At the end you wrote "Please identify your device and confirm that it has more than 4MB flash."

I have identified my device more then exactly by writing:
"The device: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/image/legacy.mk#L269 "

Now you know the model number, the hardware revision and that the ROM is been partitioned in parts of

  1. 256k(u-boot - bootloader)
  2. 64k(u-boot-env - bootloader configuration)
  3. 3712k(openwrt firmware)
  4. 64k(art - wifi calibration data + MAC address)

What more identification did you need? Why should i confirm that the device have more then 4MB of flash, when nowhere is been mentioned that it would have more then 4MB of flash? The wiki here is not wrong:
https://wiki.openwrt.org/toh/netgear/WNR2000#hardware_highlights

Could someone port the device from the legacy openwrt/target/linux/ar71xx/image/legacy.mk
to openwrt/target/linux/ar71xx/image/generic.mk ?

What is the reason why this is specially for tp-link and not just generic for tiny devices (named tiny-generic.mk)?
openwrt/target/linux/ar71xx/image/tiny-tp-link.mk

Thanks

Than again, you didn't see posts, (and we are all aware of the edit the title after I inquired):

Every operating system requires

Sufficient Flash to accommodate firmware image
Sufficient RAM for stable operation

Because those devices are not supported.

How about we focus on your WNR2000v3, which is a 4/32 device:
https://wiki.openwrt.org/toh/netgear/wnr2000

32 MB 4 MB

@lucize likely noted this because the developers generally do not support 4/32 devices.

This is the only proposed option for your issue at this time.

Quote:
"Than again, you didn’t see posts, (and we are all aware of the edit the title after I inquired):"

The user "hnyman" have edited the title of this thread. I have not touched it since my first post and i typically dont edit any of my posts afterwards.

I wrote:
"nowhere is been mentioned that it would have more then 4MB of flash"
You answered "Than again, you didn’t see posts,"

I really dont know where its written that this device could have more then 4MB of flash. Could you please quote that?

@devs
could you please help with changing this device from legacy to generic build form? I am willing to test the patches so that those could be merged after the tests.

LOL
https://openwrt.org/supported_devices/432_warning
https://openwrt.org/supported_devices/432_warning
https://openwrt.org/supported_devices/432_warning
https://openwrt.org/supported_devices/432_warning

From: https://openwrt.org/supported_devices/432_warning

Supportability

It is getting harder or even impossible over time to support devices with low Flash + RAM. LEDE support for those devices might end somewhere in the future.

Advice

new users knowing what they want (or not), not knowing what they need, not knowing what to do → get 8/64
experienced users knowing what they want, need, and do → try if 4/32 suits your needs; if not, get 8/64

:thinking:

HE IS A DEVELOPER!

In the links you posted now some times nowhere is written that the WNR2000v3 could have more then 4MB of ROM. Why did you post that the whole time?

You wrote "Please see this unanswered questions in that thread:"
and linked to: " Are you sure that the TP-Link TL-WA855RE really has more flash than 4 MB? "
And wrote at the end "Please identify your device and confirm that it has more than 4MB flash."

Noone have told that the WNR2000v3 could have more then 4MB of rom.

You answer then "LOL"
and link to https://openwrt.org/supported_devices/432_warning

What does that have to do with the request of moving the device from openwrt/target/linux/ar71xx/image/legacy.mk
to openwrt/target/linux/ar71xx/image/generic.mk ?

Could you please help with some productive thing? I have now checked twice your posts and was not able to find anything usefull.
We are here in the forum "For Developers". You are probably a developer because posting here, could you please send and PullRequest/Patch for the change to finally fix the issue that the image builder is creating images that are too big? The new generic.mk build process have that check and fails when its been tried to build images that wont work later on when they are too big.

READ CAREFULLY:

  • YOUR DEVICE HAS 4 MB FLASH AND 32 MB RAM
  • NOBODY IS DEBATING THIS, THE TITLE WAS EDITED TO NOTE YOUR DEVICE, WHICH HAS 4 MB FLASH AND 32 MB RAM
  • DEVICES HAVING 4 MB FLASH AND 32 MB RAM ARE NOT SUPPORTED
  • I POSTED THAT SO YOU WOULD READ BECAUSE THOSE DEVICES ARE NOT SUPPORTED; INSTEAD, YOU'RE IGNORING THE FACT YOUR DEVICE IS NOT SUPPORTED.
  • YOUR DEVICE IS NOT SUPPORTED

He is a [leading] developer on this project...so why did he edit the title and choose not to respond???

I AM NOT, BUT I CAN TEST/LOOK AT CODE/MAKE MY OWN BUG REQUESTS IF I OBSERVE SOMETHING. SO YOU CAN SEND THE REQUEST TOO, THIS IS AN OPEN SOURCE PROJECT. IT WILL LIKELY BE DENIED BECAUSE OF: https://openwrt.org/supported_devices/432_warning

YOUR 4 MB FLASH IS TOO SMALL!

YOU CAN IGNORE THE MANUAL IF YOU WISH:

and

https://bugs.lede-project.org/

Good Luck.

@lleachii - tone it down! No need to yell in all caps. The original question might relate to a 4MB device but the question on porting legacy image build code to modern image build code still has merit.

1 Like

@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