I just spent hours of greping and trying to modify all the scripts having anything in common with SPI flash size. Is it really so hard to put it into one config file to make it possible to compile the sources with different flash size? maybe I'm the only one person which is replacing chips for the larger ones, but it's really big pain. I can remember I got it in the past when I was changing 4M chip for the 8M one. I did it somehow. I don't know how - it's not important for now. I just did it. But now I'm trying to replicate it with 16M instead of 4M and I have no luck with all that greping and replacing stuff - I'm fucking upset. Is there at least some basic "like a manual" to be able to go through all the files and to modify all the values? I currently have A5-V11 board with 16M SPI and I don't have any idea how to make it work correctly and use all the flash size. Should I really spend my time to go through the all the source files? Really? Don't you be able to unify that and to put all the differences inside one or a few files? Or at least to create one single wiki page to let the users know where to find that values and modify them? Because for now I'm really really upset and I'm seeing that kind of trying of making "different linux distro" like a really highly unprofessional experiment. I'm working with linux daily, but I'm really not facing such problems at all. For now I have to choose whether I'll throw that piece of well-compressed electronics into the garbage and to buy some proprietary well-working piece of metal, or to wait for any response. To be honest, I really doubt about the useful response - I've seen the code of builder and it's really a piece of shit, so most probably I'll rely on my own compilation of linux distro, but that question costs nothing.
You do realize that embedded devices like this differ -a lot- and have very little in common between different vendors?
In contrast to your "I'm working with linux daily" devices (be it x86, x86_64 or even ARM, PowerPC, SPARC, …), routers usually don't have 'normal' block devices, with a partition table (be it DOS, GPT, BSD slices, SUN disk labels, etc.) and some kind of BIOS/ UEFI, Open Firmware/ OpenBoot, etc. which are auto-discoverable and don't need hardcoding. Most devices targetted by OpenWrt (spi-nor/ NAND flash, etc.) however don't have any concept of partition tables, but require hardcoded partition definitions via DTS/ bootloader instead.
What you would usually do, is checking the git history for the commit adding support for your device, which should be relatively clear in terms of what needs changing. In general (insofar there are any generalisms at all), you will have to check three places - DTS (hardcoded partition table), image generation makefile (size limits, to prevent oversized images) and eventually image generation helpers (e.g.
mkporayfw in your case). But if you can change the hardware, it's up to you to adapt the software side accordingly.
That said, keep in mind that you still only have 32 MB RAM, which is just as much of a problem as the 4 MB flash size (and more difficult to replace) - but an even bigger one in combination with larger flash chips. During the flashing process your new image needs to fit into the devices RAM, in addition to the normal runtime RAM usage. For 4 MB that isn't much of a problem, with 8 MB flash that is getting very tight on 32 MB RAM devices already - 16 MB flash however are quickly entering the no-go area.
Thanks for the response. I'm aware of the memory limitation and I'm fine with that (unfortunately it cannot be upgraded to 64M, but it's really not an issue for me). I tried to change it to 8Megs only. I already changed the flash layout in dts file and size in Makefile, but nothing worked - I'm ending up with filesystem/uImage/vmlinux files generated, but without final flash files (factory & sysupgrade). So there must be required another change somewhere to allow bigger file size. I even tried to change "4M" to "8M" in mkporayfw and also no luck. Althrough it's a really strange design of the builder requiring its recompilation for every new platform. These definitions should be located outside the source code.
I suppose you've been looking at target/linux/ramips/image/rt305x.mk?
define Device/a5-v11 DTS := A5-V11 IMAGE_SIZE := $(ralink_default_fw_size_4M) IMAGES += factory.bin IMAGE/factory.bin := \ $$(sysupgrade_bin) | check-size $$$$(IMAGE_SIZE) | poray-header -B A5-V11 -F 4M DEVICE_TITLE := A5-V11 endef TARGET_DEVICES += a5-v11
I assume you tried replacing
ralink_default_fw_size_16M and that didn't work?
Sorry, currently I'm trying that with older version (not the current one), so there is no such file to modify.
I will try to download the current one in case I'll find no other solution. But for now it seems that I won't find any.
One more question: I'm already realized that 15.05.01 cannot work with my flash (and I really don't want to spend any additional time to add that flash type to the source code and recompile it - it's really designed in a very strange way), so I've switched to 17.01.6. And there is the strangest thing: I can build and use the system defined for another machine like the AWM002 and have missing things like buttons or leds (because their physical assignment is really different - so it's understandable, it's okay for me), but I cannot build and use the system for my machine - it ends up with an errors about the filesystem. Okay - strange, the definitions are almost the same, but okay - maybe some strange thing. But even more I tried to change the definitions in dts folder (both for my A5-V11 and AWM002) and cleared the cache, but rebuilding the system gives the same result - I simply can do absolutely anything (maybe I can even remove those files - I didn't try it yet, but it really looks like I can) and it will still give me the same results. Is there any another not documented way (another than "make clear") to force the builder to respect the actual state of that files? Because I really can swap them all and I'm receiving the same results.
For now, I simply don't want to go deeper and to realize how it works like, because I'm expecting it should work. But it doesn't. And that's the thing which makes me crazy - I never let something like that to left my internal developing space without being sure it's working correctly and can be useable. And I definitely don't want to waste my time building my own system for that crap - I'm just happy that I can use this little thing (for those people who didn't see this "router" - it's really a piece of nothing having dimensions of common lighter). So it's also the reason why I don't want to buy something more powerful and want just to upgrade this one - I don't really care about the money, I just do care about the size and there is nothing else to choose from.
Take a look at, for example, the GL.iNet GL-MT300-V2 (16/128), GL-AR300M (128 NAND/128) -- both ~2"x2"x1", GL-AR750S (128 NAND/128, dual-band) -- roughly 3"x5"x1". For even smaller, there's the VIXMINI. They all ship with OpenWrt pre-installed, from a vendor that stays very close to the tree, publishes their source, and supports their devices.
There is a lot of other alternatives in those dimensions - I know about them. But that dimensions are too big for my application. Just take a look at the A5-V11 and you will understand