Adding OpenWrt support for ws-ap3825i

We're not out of the weeds yet. bootm_size is the only option I've seen work, but it definitely looks like it's also forcing Linux as a whole to limit to only so much RAM.

Edit: I've traced the source and confirmed that it won't be possible to coerce the fdt to relocate at a specific location. The memory management (lmb) in u-boot is bound by:

#define CONFIG_SYS_BOOTMAPSZ (160 << 20) /* Initial Memory map for Linux */

It is possible to step through manually and skip relocation, but you don't want this because a lot of cleanup and block-alignment and spacing goes into the relocation on the AP3825i.

Edit: I booted with the following options giving me enough memory (64M) not to OoM:

setenv bootm_low 0x0;
setenv bootm_size 0x4000000;
setenv bootm_mapsize 0x4000000;

From OpenWrt, I pulled /sys/firmware/fdt and decompiled (dtc -I dtb 64.fdt -o ap3825i_64mb.dts) the following dts:

https://paste.c-net.org/GrowlingWhitney

Looks like U-boot is shimming in this particular piece, which hampers us:

	memory {
		reg = <0x00 0x00 0x00 0x4000000>;
		device_type = "memory";
	};

Of course, but going from completely non-booting to starting but hitting OOM errors from some config options that just need to be played with to make it happy is definitely a nice change. Definitely easier to debug when you aren't trying to pull logs from a buffer triggered by a watchdog reset routine I'm sure.

Just glad you got to the first booting milestone!

You were right! I was way closer than I thought to the final answer.

So, long story short, the solution is:

  • Store your FIT image low -- think tftpboot or nand read to 0x2000000, not 0xa000000.
  • Use u-boot commands to unpack the FIT image. Instead of:
bootm 0x2000000;

do:

interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk;
fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go

This just skips the far-away default relocation.

Testing sysupgrade now with a completely clean build.

1 Like

Nice! I figured it wouldn't be much longer. Congrats! I'm assuming you picked up that absolute pallet of WS-AP3825i units on eBay earlier hahaha

I'm looking forward to the sysupgrade bins when they're ready, and again, thanks for all your work!

Out of curiosity, how did the sysupgrade go? Any difficulties?

Also, are you planning to submit a PR for this at some point?

Mostly asking as I'd love to be able to test the units I have here to see if they even work properly. My buddy mentioned that he'd sell me his box of them (8 units) for a few bucks if I want them. If you could post a bin for testing, I'd be pretty thankful, as I don't have a build environment set up for these at the moment to apply your changes and compile it myself.

Sysupgrade went fine.

Go get the units, they work. I still need to

  • finish fixing LEDs
  • cleaning up device tree
  • cleaning up commits
    • adding instructions to commits
    • testing with more devices
    • verify instructions don't give any problems as kernel grows larger
  • potentially drop ath10k-ct for ath10k because wave1 chipsets have poorer ath10k-ct support

Tree: https://github.com/Hurricos/openwrt/tree/add_ap3825i_rebase

Builds: https://downloads.laboratoryb.org/releases/snapshot/targets/mpc85xx/p1020/

2 Likes

Alright! I was able to tftpboot into the kernel just fine on my testing unit and it booted successfully. I noticed it didn't have luci embedded in it, but that's no issue for the moment.

I was feeling adventurous, so as you mentioned that sysupgrade was working, I figured it wouldn't hurt to try flashing it through the command line. As it turns out, that did not work hahaha

I was able to load the sysupgrade image onto the device and run the command to start the sysupgrade process inside the tftpboot launched openwrt kernel, which claimed to succeed, but on reboot it just panics about the magic bits being invalid on the decompressed kernel image, then it drops into a recovery shell. I can still easily launch OpenWRT over tftpboot in Uboot after rebooting the unit, so it's not an issue, just figured I'd report. Knowing my lack of knowledge about how uboot works, I probably just flashed it incorrectly.

The rest of the units all boot up just fine over tftpboot, so I stopped there with them. I figure in just doing something wrong, so I'll wait for a better explanation on that and read up more. I'm satisfied just knowing that they all worked.

Thanks again, and great job on this! As I said, I'm happy to help test if you want to send me some things to try. I'm not worried about bricking this unit haha

1 Like

It might be that I'm not cleanly padding the kernel split, it automatically creates the partition but I probably should pad the kernel to a clean eraseblock length.

Okay, so just to make sure I'm clarifying properly, here's the steps and commands I took to flash the sysupgrade file.

-------
Setup
-------

setenv ipaddr 192.168.2.45
setenv serverip 192.168.2.30
tftpboot 0x2000000 openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-initramfs-kernel.bin
interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go


-------
Network Config
-------

uci set network.lan.ipaddr="192.168.2.45"
uci set network.lan.gateway="192.168.2.1"
uci set network.lan.dns="192.168.2.1"
uci commit
/etc/init.d/network restart

-------
Flash
-------

mkdir /tmp/sysupgrade
cd /tmp/sysupgrade
wget https://downloads.laboratoryb.org/releases/snapshot/targets/mpc85xx/p1020/openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-squashfs-sysupgrade.bin
sysupgrade -v /tmp/sysupgrade/openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-squashfs-sysupgrade.bin

From here, the system completes the process and then reboots. Here's my complete log starting from power-up to booting from tftp to running sysupgrade to the reboot and subsequent boot fail.

https://paste.c-net.org/MergerAmmonia

As I said, I can reboot and relaunch from uboot, but a regular reboot doesn't work right now for some reason. As I said, could be that I'm not doing the sysupgrade correctly, but that seems about right from my research anyway. Let me know your thoughts.

You also need to set the bootcmd correctly. This one will work:

setenv bootcmd 'cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go;'
1 Like

Hmm, still not getting a good boot from NAND. Here's the result when I do the flash and update the setenv bootcmd data.

https://paste.c-net.org/RosaryProduced

Not sure what's happening there. Interesting that it notifies about the magic bitmask only the first time after flashing. Subsequent reboots just note that the primary kernel is missing and proceeds to boot the secondary.

I can probably set things up so you can remote into one of my laptops attached to the AP with a wifi smart switch available for hard reboots or something. Let me know if you think something like that would be useful.

As a note, when I go back to try straight up running the boot command provided from uboot, it gives me this:

Boot (PRI)-> cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go
Wrong Image Format for bootm command
ERROR: can't get kernel image!
   XIP Invalid Image ... OK
OK

EDIT:

So, if I do a clean setup, flash the kernel, and interrupt uboot before it can start messing with things, the bootcmd provided works to load the kernel from NAND. If you reboot without interrupting uboot, it kills it again. Seems to be having trouble setting and retaining the setenv bootcmd variable. Any ideas?

EDIT2:

Ok, I figured out where I'm messing up. I needed to run a "saveenv" command right after setting the variables in uboot. By the way, there's a lot of junk in there.

Here's the default environment environment variables for reference.

AC_HOSTNAME=Controller
AP_FLAG=0
AP_MODE=0
BOOT_BOOTROM="U-Boot 2010.12.6 (Mar 09 2016 - 19:56:30)"
BOOT_KERNEL=primary
CRYPTO_FLAG=3
CURR_VER=U-Boot 2010.12.6 (Mar 09 2016 - 19:56:30) (primary)
DEFAULT_SETTING=0
HW_RELEASE=513
LOGHDR=0xfffec00
LOGHDRRREASON=0xfffec24
MODEL=AP3825i-1
MOSTRECENTKERNEL=0
NUM_ANTENNAS=6
RADIOADDR0=D8:84:66:73:6C:10
RADIOADDR1=D8:84:66:73:6C:18
REBOOT_PATTERN_WDG=0x5A5A5A5A
REGION=NA
SERIAL#=16453819085M0000
SERVICEATTRS=ac_manager,ru_manager
SERVICETYPE=siemens
VERSIONBASE=0
WATCHDOG_COUNT=0x00000001
WATCHDOG_LIMIT=3
WLAN_ORDER_STRING=10
baudrate=115200
boot_diag=if fsload 0x0A000000 diag.gz.uImage; then if imi 0x0A000000; then bootm 0x0A000000 - -; exit; fi; fi;echo ERROR: Problem with diag image, dropping to interactive shell
boot_flash=source boot_kernel
boot_net=tftpboot 0x0a000000 vmlinux.gz.uImage.3825; bootm 0x0a000000 - -
bootargs=console=ttyS0,115200n81  panic=30 ro mtdparts=ec000000.nor:62848K(FS),128K(CALIB),512K(BootPRI),128K(NVRAM1),128K(NVRAM2),128K(NVRAM3),128K(NVRAM4),128K(NVRAM5),128K(NVRAM6),128K(NVRAM7),128K(NVRAM8),128K(CFG2),128K(CFG1) BOOT_KERNEL=primary BOOT_BOOTROM="U-Boot 2010.12.6 (Mar 09 2016 - 19:56:30)"
bootcmd=run boot_flash
bootdelay=2
eth1addr=D8:84:66:78:DC:F5
ethact=eTSEC1
ethaddr=D8:84:66:78:DC:F6
filesize=74
mem=261632k
menucmd=run boot_diag
mtddevname=FS
mtddevnum=0
mtdids=nor0=ec000000.nor
mtdparts=mtdparts=ec000000.nor:62848K(FS),128K(CALIB),512K(BootPRI),128K(NVRAM1),128K(NVRAM2),128K(NVRAM3),128K(NVRAM4),128K(NVRAM5),128K(NVRAM6),128K(NVRAM7),128K(NVRAM8),128K(CFG2),128K(CFG1)
netdev=eth0
partition=nor0,0
static_bootargs=console=ttyS0,115200n81  panic=30 ro
stderr=serial
stdin=serial
stdout=serial
uboot=u-boot.bin
ver=U-Boot 2010.12.6 (Mar 09 2016 - 19:56:30) (primary)

Environment size: 1871/65531 bytes

For anyone following along, here's the complete process (though you'll need to specify your own IP addresses for your tftp server)

-------
Setup
-------

setenv ipaddr 192.168.2.45
setenv serverip 192.168.2.30
setenv bootcmd 'cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go'
saveenv
tftpboot 0x2000000 openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-initramfs-kernel.bin
interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go

-------
Network Config
-------

uci set network.lan.ipaddr="192.168.2.45"
uci set network.lan.gateway="192.168.2.1"
uci set network.lan.dns="192.168.2.1"
uci commit
/etc/init.d/network restart

-------
Flash
-------

mkdir /tmp/sysupgrade
cd /tmp/sysupgrade
wget https://downloads.laboratoryb.org/releases/snapshot/targets/mpc85xx/p1020/openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-squashfs-sysupgrade.bin
sysupgrade -v /tmp/sysupgrade/openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-squashfs-sysupgrade.bin

Following that, you should let openwrt start up and then run these (with your chosen IPs again)

uci set network.lan.ipaddr="192.168.2.45"
uci set network.lan.gateway="192.168.2.1"
uci set network.lan.dns="192.168.2.1"
uci commit
/etc/init.d/network restart
reboot

After rebooting, then you can install luci with these commands:

opkg update
opkg install luci

Everything seems to work just fine from there, other than the previously listed limitations of course.

1 Like

Yeah, you got it :smiley:

I thought the saveenv would be obvious, but I forgot you mentioned you didn't have much experience playing with U-boot.

1 Like

Yup, seems to be working on 4 units successfully so far, including the luci interface. All running good now.

Notes:

Directly after running the first boot after flashing OpenWRT from the TFTPboot session, wait. OpenWRT seems to need to do some setup of the partitions before unlocking it for writing configuration information. My advice, once the system stops lagging enough for you to be able to open the shell, just enter the 'reboot' command and wait it out. It'll look like it's doing nothing, but just keep waiting. The reboot command can't work until all other processes successfully exit from what I can tell, so it'll just sit there in terminal until the setup process completes and then reboots the AP. You can continue setup from there. If you try to do anything before that, it just drops the config changes and they're gone on reboot, including any installed packages.

Also, if you're having issues with NTP or downloading, you can use these commands as alternatives to bypass those issues.

-------
U-Boot Login
-------

[Press Enter to halt boot process]
Username: admin
Password: new2day

-------
Setup
-------

setenv ipaddr 192.168.2.47
setenv serverip 192.168.2.30
setenv bootcmd 'cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go'
saveenv
tftpboot 0x2000000 openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-initramfs-kernel.bin
interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go

-------
Network Config
-------

uci set network.lan.ipaddr="192.168.2.47"
uci set network.lan.gateway="192.168.2.1"
uci set network.lan.dns="192.168.2.1"
uci commit
/etc/init.d/network restart

-------
Flash
-------

mkdir /tmp/sysupgrade
cd /tmp/sysupgrade
wget --no-check-certificate https://downloads.laboratoryb.org/releases/snapshot/targets/mpc85xx/p1020/openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-squashfs-sysupgrade.bin
sysupgrade -v /tmp/sysupgrade/openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-squashfs-sysupgrade.bin


-------
On flash completion
-------

reboot

//Wait until command completes

-------
Reconfigure Network
-------

uci set network.lan.ipaddr="192.168.2.47"
uci set network.lan.gateway="192.168.2.1"
uci set network.lan.dns="192.168.2.1"
uci commit
/etc/init.d/network restart

-------
Install LuCI
-------

opkg update --no-check-certificate
opkg install luci --no-check-certificate
reboot
1 Like

Yeah, the initial setup is the JFFS2 filesystem getting structured before the overlayfs can mount.

2 Likes

Just a general heads up, but I've successfully run through the flashing process on all 9 of my units with no issues. Both WLAN cards come up without issues, and though I haven't run any of them long term yet, the one I'm testing doesn't appear to be giving out under load or anything. All in all, seems solid. Not like the LEDs are overly important, but seems to be that is otherwise pretty stable even just as is running LuCI. I haven't tried any other secondary packages mind you, but I'll get there. Hopefully meshing will work well once I have time to set that up.

Thanks again, and I'm glad these units are finally useful!

1 Like

I'll fix the LEDs tomorrow -- preparing my workspace tonight.

2 Likes

Up to three days of uptime here now, and all good. Been running it fairly hard as well. Lots of stuff with streaming Miracast over infrastructure, which is pretty bandwidth intensive, but no issues or unexpected levels of lag. Haven't tested the 2.4G card yet as far as a sustained bandwidth test over a longer period of time is concerned, but it hasn't dropped out or anything from what I can tell. I have two set up now with 802.11r fast roaming enabled for mesh, and it works as expected. No issues from what I can tell.

Hope your workstation setup is going well. I know I've been burnt out from moving into my new house with my partner, and setup for my workstation is barely half done after a month. It's rough hahaha

2 Likes

congrations, it is very good news befor newyear :100:
i go to tes this build and instructions :wink:
nice, board is starting

how version show this line?

DISTRIB_DESCRIPTION=OpenWrt SNAPSHOT r18216+1-a662d8550f

Not sure what you're saying here. Are you running into kernel vermagic issues when trying to install e.g. kmod packages?