The latest build (r13762-358aec7775) is dating back to July 09th 2020 despite the advance of kernel version in the repo since then. Have buildbots been stopped for that that target or is kernel compilation failing (did not find anything in the fail logs)?
http://builds.openwrt.org/master/images/builders/mvebu%2Fcortexa9 - it is not building atm
Since it hasn't been mentioned yet, the root cause is:
WARNING: Image file /builder/shared-workdir/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linksys_wrt1900ac-v1-kernel.bin is too big WARNING: Image file /builder/shared-workdir/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linksys_wrt32x-kernel.bin is too big
When I disable both unfortunate devices with 3 MiB kernel partition, buildbot config compiles fine on my local machine. PR#3205 tries to address the issue, but probably will take time.
iff --git a/target/linux/mvebu/image/cortexa9.mk b/target/linux/mvebu/image/cortexa9.mk index 5f3236743..035ce5541 100644 --- a/target/linux/mvebu/image/cortexa9.mk +++ b/target/linux/mvebu/image/cortexa9.mk @@ -109,7 +109,7 @@ define Device/linksys_wrt1900ac-v1 DEVICE_PACKAGES += mwlwifi-firmware-88w8864 KERNEL_SIZE := 3072k endef -TARGET_DEVICES += linksys_wrt1900ac-v1 +# TARGET_DEVICES += linksys_wrt1900ac-v1 define Device/linksys_wrt1900ac-v2 $(call Device/linksys) @@ -142,7 +142,7 @@ define Device/linksys_wrt32x KERNEL_SIZE := 3072k KERNEL := kernel-bin | append-dtb endef -TARGET_DEVICES += linksys_wrt32x +# TARGET_DEVICES += linksys_wrt32x define Device/marvell_a370-db $(Device/NAND-512K)
That is the dilemma with this target class, mixing boards with a vast difference in hardware capabilities.
Their launch dates (2014 | 2015) aside how contemporary is 3 MiB kernel partition space in 2020, that for a router and not some sort of IoT device?
Every operating system requires Sufficient Flash to accommodate firmware image Sufficient RAM for stable operation
And on the other hand the mentioned PR tries to accommodate 3 MiB kernel partition space, which appears to be a rather insufficient size limitation.
The kernel code is likely to grow to a point where its compiled image will not fit any more on 3 MiB, with the current build failure being a case in point already, no matter what.
for my own clarification:
would expansion of the kernel partition require extensive bootloader modification? it would seem that in U-Boot at least, the mtd map could be reallocated from the U-Boot command line, or through a careful series of fw_setenv statements and a mtd write to the new partition - so there may be a way forward?
The venom is much more recent than 2014.
Have not checked whether the flash layout is defined for the wrt1900ac (https://openwrt.org/toh/linksys/linksys_wrt1900ac) through DTB and thus flexible or somewhere else set in stone.
The curious thing is the seemingly wasted (unused) space of MTD9, aside from providing a dual-boot partitioning and another 40 MiB gone with MTD6.
If the layout is flexible through DTB it might be a way to consider, make use of the wasted/unused MTD9 space and/or perhaps transform the device into the a single-boot device (80 MiB).
mtd4 / mtd6 - are basically the two partitions providing the dual boot failsafe mechanism. Preserving the flash layout, as defined in the DTS provided from upstream, allows reverting back to OEM.
Does the OEM code require all of the 40 MiB or can some be contributed to the OpenWrt installation?
What about the unused space of MTD9?
What about increasing the kernel partition from 3 MiB to 5 MiB and decreasing the rootfs partition proportionally?
Sooner than later the size limitation of 3 MiB will just not suffice any-more.
I assume that partition layout modification is a non-starter. dengqf6 bought a lot of kernel space during the 5.4 PR interation cycle by removing some unused FS modules; this was part of the (non)NEON target separation which fell by the wayside.
I'm not sure how anyone can currently build an image though. I have not been able to build since the last procd push due the_jail.c_ error, which neheb has apparently submitted a number of patches which are not being pushed to master.
i agree best to keep the mtd config as close to oem as possible.
the wrt1900v2 has the same mtd allocation, but a 6mB kernel with 3mB smaller (34mB) rootfs in the same 40mB mtd.
it would seem an acceptable tradeoff.
So, used one of neheb patches to allow build to finish and all wrtpac kernels are generated with room still available on the 2 3MB kernel partition devices:
3064213 Jul 23 18:44 linksys_wrt1200ac-kernel.bin 3064213 Jul 23 18:44 linksys_wrt1900acs-kernel.bin 3054882 Jul 23 18:44 linksys_wrt1900ac-v1-kernel.bin 3064197 Jul 23 18:44 linksys_wrt1900ac-v2-kernel.bin 3050160 Jul 23 18:44 linksys_wrt3200acm-kernel.bin 3050090 Jul 23 18:44 linksys_wrt32x-kernel.bin
not sure why there is an issue with the bot generation. This is also with -O2 optimisation so things should actually be larger than the default -Os.
you have much greater facility than I do. your 3mB solutoin might be great.
i was suggesting that a 6mB kernel scheme had already been accomplished for the wrt1900ac V2, by splitting the 40mB partitions into 6 mB (kernel) = 34mB (rootfs)
No firmware of this world will fit into 40 milli Byte.
You should get used to using the correct multiplicators.
It does make a difference if you have 40 milli $ or 40 Mega $ on your bank account.
you are so correct. 40 MiB . forgive me and thnak you for pointing out my error..
The problem here non technical here but political, OpenWRT maintainers do not want to split up the builds for mvebu, claiming that extra target will consume extra 10 MB disk space on the build servers, which they do not want mvebu to have, even though other targets do not get such scrutiny. As such until local politics changes nothing really could be done.
Source of this information?
@tmomas Please read the reply by jow linked below:
You may read the whole thread for this pull request as well, there were other posts by jow and other maintainers to the same extent.
This pull request was all about solving this problem.
This link is probably better:
And the previous(first ?) cat kick, predating the dead-cat -bounce; which actually fell out of an attempt in the mvebu 5.4 kernel PR.
Edit: before they were them, they were great, Live At The Boston Tea Party, sad day indeed, absolutely brilliant.