Hi guys,
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. mktplinkfw or mktplinkfw2; 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_4M with 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 
HI
I trying to build OpenWrt 19.07.2 version for A5-V11 32Mb RAM.
I made a hardware modification of A5-V11 - change 4Mb to 16Mb SPI FLash.
Software modification :
target/linux/ramips/image/rt305x.mk :
define Device/a5-v11
DTS := A5-V11
IMAGE_SIZE := 15872k
IMAGES += factory.bin
IMAGE/factory.bin := \
$$(sysupgrade_bin) | check-size $$$$(IMAGE_SIZE) | poray-header -B A5-V11 -F 16M
DEVICE_TITLE := A5-V11
DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2
DEFAULT := n
endef
TARGET_DEVICES += a5-v11
target/linux/ramips/dts/rt5350_unbranded_a5-v11.dts :
m25p80@0 {
compatible = "jedec,spi-nor,W25Q128FV";
reg = <0>;
spi-max-frequency = <10000000>;
partition@50000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x50000 0xfb0000>;
};
firmware-utils/src/mkporayfw.c
static struct flash_layout layouts[] = {
{
.id = "4M",
.fw_max_len = 0x3c0000,
}, {
.id = "8M",
.fw_max_len = 0x7c0000,
}, {
.id = "16M",
.fw_max_len = 0xfb0000,
}, {
/* terminating entry */
}
};
static struct board_info boards[] = {
{
.id = "A5-V11",
.hw_id = HWID_A5_V11,
.layout_id = "4M",
.key = KEY_A5_V11,
}, {
.id = "A5-V11",
.hw_id = HWID_A5_V11,
.layout_id = "16M",
.key = KEY_A5_V11,
},
I get firmware :
openwrt-ramips-rt305x-unbranded_a5-V11-squashfs-sysupgrade.bin 11521K size
then i copy the firmware to /tmp on A5-V11 and flashing it :
sysupgrade -F -n /tmp/openwrt-ramips-rt305x-unbranded_a5-V11-squashfs-sysupgrade.bin
But when router booting i get error :
Please tell me where I was wrong.
Thanks.
Show full log pls. I think that spi-driver don't recognize this:
May be you mean
compatible = "jedec,spi-nor", "W25Q128FV";
?
Normal boot must look like:
[ 0.340000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 0.360000] serial8250: ttyS0 at MMIO 0x10000500 (irq = 13) is a 16550A
[ 0.370000] serial8250: ttyS1 at MMIO 0x10000c00 (irq = 20) is a 16550A
[ 0.390000] ramips-spi ramips-spi.0: master is unqueued, this is deprecated
[ 0.410000] m25p80 spi0.0: found w25q128, expected pm25lq032
[ 0.420000] m25p80 spi0.0: w25q128 (16384 Kbytes)
[ 0.430000] 6 cmdlinepart partitions found on MTD device spi0.0
[ 0.440000] Creating 6 MTD partitions on "spi0.0":
[ 0.450000] 0x000000000000-0x000000030000: "u-boot"
[ 0.460000] 0x000000030000-0x000000040000: "u-boot-env"
[ 0.480000] 0x000000040000-0x000000050000: "factory"
[ 0.490000] 0x000000050000-0x000000130000: "kernel"
[ 0.500000] 0x000000130000-0x000000400000: "rootfs"
[ 0.520000] mtd: partition "rootfs" set to be root filesystem
[ 0.530000] mtd: partition "rootfs_data" created automatically, ofs=380000, len=80000
[ 0.550000] 0x000000380000-0x000000400000: "rootfs_data"
[ 0.560000] 0x000000050000-0x000000400000: "firmware"
So at least correct compatible string.
Many thanks !!! you make my day !
you were right - it worked !
Hi, any chance you still run this small bad boy and have any image? I'm total noob in terms of OpenWRT compiling. 
Thank you!
To which size have you upgraded the flash of your device?
I have a few flash chips of various capacities lying around, but I was thinking about the 16MB as OP.
There is one significant disadvantage of upgrading to 16MB - too low free RAM. But you can switch to 8MB image at any time (I did the same 
). As it's not possible to build the image on m1 macs now, I'm using this image (I don't care about not working LEDs): https://downloads.openwrt.org/releases/19.07.10/targets/ramips/rt305x/openwrt-19.07.10-ramips-rt305x-m4-8M-squashfs-sysupgrade.bin
By the way: although 21.02.x can be installed on it as well, I got irresponsible machine having kernel workers utilizing significant amount of CPU. I don't know whether it's a general issue or just an issue of my setup. So just be aware of that.