The firmware partition is not new space, it is a sort of alias defining the combined kernel + rootfs spaces which are adjacent in the chip.
OpenWrt leaves the "cfg" partition matching what the stock firmware does, but it leaves data there unchanged as reserved space in case someone wants to go back to stock firmware. If you're not going to do that you can get rid of cfg and bring that 256 kB into rootfs to have more overlay space.
Ok, I see.
I have tried the same partition scheme that the ar724x_ubnt_xm.dtsi because it a 8 MB flash:
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
uboot: partition@0 {
label = "u-boot";
reg = <0x0 0x40000>;
read-only;
};
partition@40000 {
label = "u-boot-env";
reg = <0x40000 0x10000>;
read-only;
};
partition@50000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x050000 0x750000>;
};
partition@7a0000 {
label = "board_config";
reg = <0x7a0000 0x010000>;
read-only;
};
partition@7B0000 {
label = "cfg";
reg = <0x7B0000 0x40000>;
read-only;
};
art: partition@7F0000 {
label = "art";
reg = <0x7F0000 0x10000>;
read-only;
};
};
But just intalling with sysupgrade is not enough:
root@OpenWrt:/# sysupgrade /tmp/openwrt-snapshot-r18371\+1-5a4685cfa2-ath79-gene
ric-ubnt_unifi-ap-outdoor-squashfs-sysupgrade.bin
Cannot save config while running from ramdisk.
Sun Dec 19 13:58:10 UTC 2021 upgrade: Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=3
- watchdog -
Watchdog has previously reset the system
Sun Dec 19 13:58:12 UTC 2021 upgrade: Sending TERM to remaining processes ...
Sun Dec 19 13:58:16 UTC 2021 upgrade: Sending KILL to remaining processes ...
[ 133.503876] sh (2608): drop_caches: 3
Sun Dec 19 13:58:22 UTC 2021 upgrade: Switching to ramdisk...
Sun Dec 19 13:58:26 UTC 2021 upgrade: Performing system upgrade...
[ 137.351298] sh (2608): drop_caches: 3
Unlocking firmware ...
Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
.File /tmp/sysupgrade.tgz does not exist
Sun Dec 19 13:59:35 UTC 2021 upgrade: Upgrade completed
Sun Dec 19 13:59:36 UTC 2021 upgrade: Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 207.016708] reboot: Restarting system
U-Boot unifi-v1.5.2.206-g44e4c8bc (Aug 29 2014 - 18:01:57)
DRAM: 64 MB
Flash: 8 MB
PCIe WLAN Module found (tries: 1).
Net: eth0, eth1
Board: Copyright Ubiquiti Networks Inc. 2014
Hit any key to stop autoboot: 0
Board: Ubiquiti Networks AR7241 board (e532-7.0101.002a)
UBNT application initialized
## Booting image at 9f050000 ...
Bad Magic Number
ar7240>
Do I have to change the bootloader env variables?
Both ar724x_ubnt_xm.dtsi ar7241_ubnt_unifi.dts have the same flash layout so mine should be the same.
But from the u-boot output, it seems to me that the kernel is not at the right address, isn't it?
If I want to add support in OpenWRT, I guess I should keep it as it is done for other Unifi devices.
From my sysupgrade logs, do you have an idea why the flash does not work?
Is it a bootloader env issue? A flash partitioning issue in the DTS? Or a write issue on the flash?
That looks like it should have worked. Try booting from RAM again and dump the flash to confirm that the sysupgrade file was properly written starting at offset 50000. Also binwalk the sysupgrade you built to see if it looks similar to release ones for similar AR7240 targets. Maybe the kernel is in the wrong binary format.
it looked like it worked, you need to show us the boot log after flashing. a "successful" sysupgrade procedure is not the same as a "successful flash" (for example, if the kernel was placed in the wrong address).
Is there any progress on this?
No, sadly, I did not mange to find the time to proceed on this.
But the router is still on my desk so I might get back to work later.