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.
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.
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."
Now you know the model number, the hardware revision and that the ROM is been partitioned in parts of
256k(u-boot - bootloader)
64k(u-boot-env - bootloader configuration)
3712k(openwrt firmware)
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
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.
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
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.
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.
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
@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.
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.
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.
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)
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):
