Unusual (?) NAND flash layout on Aruba AP-325

For Developers
1

Hi all,

I’m currently working on porting OpenWrt to the Aruba AP-325, and while it’s mostly working so far (LAN, WLAN, LEDs, buttons etc.), I’m not certain how to handle the NAND flash layout.

Short device summary:

  • SoC: Qualcomm Atheros IPQ8068
  • Radio: 2x QCA9990 (one for 2.4G, one for 5G, each 4x4-MIMO)
  • LAN: 2x 1GbE
  • DRAM: 512 MB
  • SPI Flash: 4 MB (MX25U3235F)
  • NAND Flash: 128 MB (W29N01HZ)

The SPI Flash has the usual platform stuff (SBL, Calibration, TZ, APPSBL etc.) and boots into “APBoot”, which appears to be a vendor-specific, heavily customized U-Boot fork.

The NAND Flash has three MTD partitions: aos0 (32 MB), aos1 (32 MB) and ubifs (64 MB). Each of them is formatted as UBI and contains one volume with the same name.

The bootloader verifies the existence of all three volumes and re-formats if they’re not detected. It then proceeds to read aos0, verifies a vendor-specific header and boots into the uImage following the header. If the verification fails, it tries the same with aos1. On top of that, it has some helper commands - e.g. osinfo shows version info embedded in the vendor header, upgrade os fetches an image per TFTP and flashes it into aos0 , clear cache wipes ubifs etc.

The vendor firmware bundles all applications, configuration etc. into the initramfs and has no dedicated rootfs. Therefore, the aos0/aos1 partitions are self-contained, and ubifs is used as the persistence overlay.

So far, so good. I’m now at the point where I have an initramfs image that boots fine if I load it via TFTP or flash it onto aos0, but I’m struggling with the best way of partitioning the device to make the sysupgrade process elegant without breaking the bootloader’s expectations.

The best I’ve come up with so far is:

  • Shrink the aos0 UBI volume in the aos0 partition to ~4 MB and write the kernel into it
  • Create an additional rootfs UBI volume in the same partition and write the rootfs into it
  • Shrink the ubifs UBI volume in the ubifs partition to 1 sector
  • Create an additional rootfs_data UBI volume in the same partition

This boots fine, but is incompatible with the current nand.sh sysupgrade logic since that expects the rootfs and rootfs_data to be on the same partition. Additionally, it seems silly to maintain the dummy ubifs volume just to make the bootloader happy, it’d be better to just make OpenWrt use the ubifs volume at the rootfs_data.

On top of all that, there’s the question of how to make proper use of the dual-image layout. The kernel part is easy since the bootloader will pick one, but it’s unclear how to make them pick the right rootfs.

Bad solutions I can think of so far:

  • Write custom sysupgrade logic for the device
  • Build a patched bootloader to disable the repartitioning logic
  • Build a patched bootloader to support setting kernel arguments based on active partition
  • Patch the kernel for this device to pick the correct rootfs
  • Just ignore the whole dual image thing

So, my questions for now would be:

  • Is there a way to change the name of rootfs_data?
  • Is there a way to just append the rootfs to the kernel instead of having a separate partition/volume for it?
  • Does this sound similar to an existing device that I could look at for reference (I couldn’t find any)?

Any other input/suggestions/etc. is of course also welcome!

4 Likes
Support for Aruba (i)AP-325?
2

That’s a great news you got Openwrt works on the AP325. I have a few of them laying around at work.

3

I’m very excited about this. I have one to test already and had looked into the original bootloader source code but was out of my depth.

Interested in helping out to test as these dual PoE input AP’s are available in my area, whilst others (Extreme / FortiWifi) aren’t.

I’ll have a go flashing the bootloader soon. Do you have patches / an openwrt branch available? I note the bootloader readme already indicates the new layout is two 64mb partitions?

4

That’s a bit late, I’ve seen You’ve made a modified U-Boot already (mentioned in other topic).

You’ve written that all partitions are UBI, which means the vendor APBoot can boot kernel inside UBI, OpenWrt can make such images. Does the bootloader check the size of UBI volumes? If not, shrink ubifs to one or two sectors and recreate/expand aosx volumes to rest of available space (each with same size). That way You won’t have to replace bootloader, which should be always a last resort.

5

I still need to clean it up and test the watchdog handling, I’ll post it here once I’ve done that.

It doesn't check the UBI volumes themselves, but the layout has three MTD partitions where each contains one UBI volume, and the MTD layout is hardcoded.

Besides, the stock APBoot also has RSA signature verification during the boot process, so it would need to be modified somehow in any case.

1 Like
6

It won’t try to re-provision the partitions if the layout (sans sizes) is preserved?

Well, that’s endgame, if all boot commands always verify the signature, then there’s no other way than replacing bootloader.