[FS#40] lede-ar71xx-generic-uImage-lzma.bin (from trunk de165b66be4) for a WNR2000v1 is too big

LEDE Bugs lede-bugs at lists.infradead.org
Mon Jan 2 12:49:39 PST 2017


The following task has a new comment added:

FS#40 - lede-ar71xx-generic-uImage-lzma.bin (from trunk de165b66be4) for a WNR2000v1 is too big
User who did this - Mark Williamson (mjw99)

----------
Dear Huan,

First thank you for all your work on this; it's very much appreciated. To cut a long story short, I was able to install your precompiled images (from Google drive) and I have a fully working router. However, let me share the initial path that I took. 

My WNR2000v1 was initially running a version of OpenWrt (15.05.1 r49053 from git://git.openwrt.org/15.05/openwrt.git) with quite a few bits stripped out. However, in later versions on that branch, there was quite a bit of ongoing regression with the wireless resulting in very large ping times. I was now quite keen to try out LEDE.

Hence I was looking to use your protocol as a template for a migration route without having to resort to using the serial port (I was just being lazy at that point). I initially noticed that a key component was the modification of the u-boot environment variables pertaining to the MTD partition sizes. My plan was to use fw_setenv and then write the LEDE images using mtd, all via ssh. This protocol worked, however, my mistake was that I used a daily build version of LEDE (https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/). This uImage file was actually too big (1,352,985 >  1,310,720 (i.e. 0x140000)) and this overwrote the ART partition. Also, upon later inspection, via serial, U-Boot was complaining about a "Bad Data CRC" for this image.

I then resorted to using my serial port and I restored the ART partition from an earlier backup that I had made (I dd backed up everything from the factory install before I even started with the this the other year).

I then proceeded to clone Jan 1st's LEDE's git tree and compile a standard image for this router (Target System --> (Atheros AR7xxx/AR9xxx) and Target Profile --> (NETGEAR WNR2000V1)). This produced an uImage file less than 0x140000 in size and I was able to use uboot's tftpboot functionality to install this and the root file system. This booted fine and worked, however, it was not able to correctly initialise the overlay mount, hence it lost it's state after reboot. I was seeing these warnings pertaining to this:

[   16.197014] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
[   16.205538] jffs2: empty_blocks 8, bad_blocks 0, c->nr_blocks 9


Finally, I repeated the above with your google drive images (r2449-7c47f43) and this worked fine; the overlay mount worked correctly. 

Do you have any idea why the overlay mounts did not work with my local compile? Have I missed something?

Thanks again,

Mark
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=40#comment1141



More information about the lede-bugs mailing list