I'm new to LEDE, but have used OpenWRT a few times before. I'm having a spot of bother with a new platform I'm trying out.
It's an unbranded device superficially very similar to a supported A5-V11, but the silkscreen reveals it's actually an A5-v1.2 and has only 4M flash and 16M RAM. The stock firmware was not receptive of a stock LEDE 'sysupgrade' image, but it had an open telnet port so I was able to use wget and mtd tools to replace the bootloader with a prebuilt uBoot (the 128mb one from here: https://yadi.sk/d/ubSsjNZU34Xk2L) and then an A5-V11 image built from the current HEAD with default settings.
It boots up fine, but there isn't a lot of free memory unsurprisingly. The upshot of this is that it's not possible for me to use the sysupgrade utility as there is not enough spare RAM to take the new image. (Free reports less than 1M free once I have logged in.)
Would it be possible to pipe the image into mtd write via netcat or ssh, or would that be a bad idea?
I read that it's possible to free up more RAM by altering SquashFS block size. How do I do so?
I bought a bunch of these as they were offered very cheap (2GBP each), gambling on them being the same as A5-V11. Externally, the case is very similar. These are black, but have a textured finish to the top and bottom surfaces.
If I can, I'd like to try making a BATMAN mesh out of them.
How much of your precious lifetime are you willing to invest in making this device work?
No pun intended, it's just that I never understood why people are buying underpowered devices with just 16MB RAM, knowing that there is trouble ahead. I'm not saying it's impossible, but thinking of how "easy" things are with 32MB compared to 16MB, I'd ask myself if lifetime_spent_solving_problems vs. money_saved is in a healthy balance.
Last but not least: If there are any useful findings, don't hesitate to document them in the wiki (until the wikis are merged, make this the OpenWrt wiki).
I configured and rebuilt a cut down LEDE following the advice on faq/before_installation, then piped it into the largest mtd device from the table above thus:
You could use the serial console, bootloader and TFTP to flash. There is probably no way to upgrade online since the RAM is so small.
Slash everything that you can out of the image. All the kmods even if not necessary still boot into RAM. If you look at ps you see that every userspace daemon like ntpd, odhcpd, dnsmasq occupies at least 1 MB.
Busybox is made to save flash but at a cost of more RAM, even a simple operation like ls loads the whole Busybox binary of 1.3 M or so. It may be better to use the coreutils compiled separately.
I would say use an old version but BATMAN doesn't link across versions of itself, and since it is a kmod, the version of BATMAN you have is tied to the kernel version.
Soldering to swap in a 32 MB RAM chip is likely possible, but difficult due to the number of pins.
Piping the image via ssh into mtd seems to work fine as it doesn't require any RAM (see above).
Thanks for the advice. I think when busybox forks though, as with any Linux process, it's not actually making a copy of itself in RAM, just the context only, i.e. fds and open sockets and such. So I will stick with it for now.
I am using the separate ulibc version of wget as I'd like to be able to send POST requests to a server ultimately which I don't think the busybox wget can do. (at least not the version used in LEDE at the moment.)
I did wonder about swapping out the SDRAM for some of these ones, but it's very tight in there. If I were to buy some, do they have to be grade -6, or could I get away with -5s?
So, does anyone know how to change block size on SquashFS?
So, does anyone know how to change block size on SquashFS?
Only way I know is when compiling from source, and in "make menuconfig" interface you travel into Target Images, then squashfs, and there you can set the block size.
Soldering to swap in a 32 MB RAM chip is likely possible, but difficult due to the number of pins.
Much less than it looks like, you just solder them without caring much about the mess (as long as they are soldered to the board), then use some solder wick to suck up all the solder between the pins. Due to superficial tension, the solder between the pins and the board won't be removed by the wick. (youtube videos can teach this technique)
Using a tiny tipped soldering iron also helps.
Also having a hot air SMD rework station or tool (basically a small hot air gun with temperature control so you don't cook the board), it's rather boring but relatively easy. (youtube videos explain this way too)
I did wonder about swapping out the SDRAM for some of these ones3, but it’s very tight in there. If I were to buy some, do they have to be grade -6, or could I get away with -5s?
You could also try to reduce the fragment cache number. By default it caches 3 fragments, but it's configurable using make kernel_menuconfig -> File systems / Miscellaneous filesystems / Additional option for memory-constrained systems. 1 or 2 would use less RAM, but may increase the CPU load. I haven't been able to find out exactly what a fragment is, so I don't know how much RAM it might save.
You could also try to reduce the fragment cache number. By default it caches 3 fragments, but it’s configurable using make kernel_menuconfig -> File systems / Miscellaneous filesystems / Additional option for memory-constrained systems. 1 or 2 would use less RAM, but may increase the CPU load. I haven’t been able to find out exactly what a fragment is, so I don’t know how much RAM it might save.
Setting it to 1 does indeed appear to free up a little.
Only way I know is when compiling from source, and in “make menuconfig” interface you travel into Target Images, then squashfs, and there you can set the block size.
Excellent! Thanks. A 32kB block size seems to be the sweet spot between RAM usage and the image being too big to fit in the 4MB flash.
I now have at least enough free to run the uclient version of wget, and read and write a USB - serial bridge from a shell script so I think I am all set for now. I still can't run sysupgrade, but the ssh method works well enough for my purposes.
