No,most likely adress is 0x84000000.
You need to do this safelly,that means that you build initramfs image.
Than you simply load that image using tftpboot to 0x84000000 and then use bootm 0x84000000
Then from it you sysupgrade
That's exactly what I have been doing to test new initramfs images:
Hit any key to stop autoboot: 0
(IPQ40xx) # setenv serverip 192.168.1.10
(IPQ40xx) # tftpboot 0x84000000 openwrt-ipq806x-netgear_wac510-initramfs-fit-uImage.itb
eth0 PHY0 Down Speed :10 Half duplex
eth0 PHY1 Down Speed :10 Half duplex
eth0 PHY2 Down Speed :10 Half duplex
eth0 PHY3 Down Speed :10 Half duplex
eth0 PHY4 up Speed :1000 Full duplex
Using eth0 device
TFTP from server 192.168.1.10; our IP address is 192.168.1.11
Filename 'openwrt-ipq806x-netgear_wac510-initramfs-fit-uImage.itb'.
Load address: 0x84000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################
done
Bytes transferred = 5963180 (5afdac hex)
(IPQ40xx) # bootm
######Booting kernel from FIT Image at 84000000 ...
Using 'config@1' configuration
Trying 'kernel@1' kernel subimage
Description: ARM OpenWrt Linux-4.9.82
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x840000e4
Data Size: 5927867 Bytes = 5.7 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80208000
Entry Point: 0x80208000
Hash algo: crc32
Hash value: e8dda56d
Hash algo: sha1
Hash value: 644351d3d008e487d113cfa5db891f9d14010970
Verifying Hash Integrity ... crc32+ sha1+ OK
##Flattened Device Tree from FIT Image at 84000000
Using 'config@1' configuration
Trying 'fdt@1' FDT blob subimage
Description: ARM OpenWrt netgear_wac510 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x845a75d8
Data Size: 33966 Bytes = 33.2 KiB
Architecture: ARM
Hash algo: crc32
Hash value: 8a52132f
Hash algo: sha1
Hash value: 02c3c7f38cfe36e421b0cc448739b537513cc734
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x845a75d8
Uncompressing Kernel Image ... OK
Loading Device Tree to 86ff4000, end 86fff4ad ... OK
Using machid 0x8010100 from environment
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
Then when I ran sysupgrade it all went wrong 
Tim
I appreciate this is worthy of a new topic now, so I'll start one..
Tim
Can you try sysupgrading from that?
Since I can see that generic FIT gets accepted
That's exactly what I have been doing:
tftpboot 0x84000000 openwrt-ipq806x-netgear_wac510-initramfs-fit-uImage.itb
bootm
..board boots..
copy over sysupgrade.bin to /tmp
cd /tmp
sysupgrade -v openwrt-ipq806x-netgear_wac510-squashfs-nand-sy
supgrade.bin
I'm googling around before I start a new topic, but I'm not getting anywhere.. I think the kernel+rootfs are in the new flash partitions, but I don't see how to get uboot to detect that.
I've added some more (hopefully helpful) logs:
Stock uboot bootlog:
OpenWrt bootlog after sysupgrade:
Tim
Interesting if I do bootipq debug:
(IPQ40xx) # bootipq debug
Saving Environment to NAND...
Erasing Nand...
Erasing at 0xef000 -- 100% complete.
Writing to Nand... done
bootargs=WAC510 ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs mtdparts=spi0.1:56m(rootfs),56m(rootfs_1),15m(var_config),768t
Booting from flash
Boot count=4
Creating 1 MTD partitions on "nand1":
0x000000000000-0x000003800000 : "mtd=0"
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd2 to ubi0
UBI: MTD device name: "mtd=0"
UBI: MTD device size: 56 MiB
UBI: number of good PEBs: 448
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 4
UBI: available PEBs: 16
UBI: total number of reserved PEBs: 432
UBI: number of PEBs reserved for bad PEB handling: 4
UBI: max/mean erase counter: 2/0
Read 0 bytes from volume kernel to 84000000
No size specified -> Using max size (2793472)
Config not availabale
bootipq failed!!
resetting ...
It seems to read that 'bootargs' variable for what partitions to boot.
Just need to figure out what the new partitions are called..
Tim
I have rebased the branch on master.
This has brought a lot of changes including using GCC7 as default and binutils 1.3
So you will need to delete the folder and do the build from scratch after cloning.
Can you make a PR including MAC fix?
Finally got OpenWrt booting off the flash! Thanks to @musashino
I modified the stock uboot bootcmd variable to do the UBI stuff, tried rebooting it again and it booted straight into OpenWrt. Modified a file, and it stayed modified after another reboot.
Full bootlog here:
Going through the Netgear init scripts, it seems there is some association of wifi IRQs with different CPU cores. I guess we need to do that too?
I'll replace one of my existing APs with this WAC510 at work tomorrow, to see how it performs.
Tim
After testing it at work with multiple VLANs and I can see that VLANs are not working. I tried reverting back to the default SSIDs that route directly to the lan interface and it all works perfectly and I get good throughput.
Given that this device has two network ports, is it possible it has a switch in it that is somehow blocking the VLANs?
Tim
yes, there's an internal-switch and it has problems with port-mapping (the pseudo portmapping stuff is implemented as a fixed vlan - that you can't edit). Sven had patches to resolve the issue for 2-Port device. From what I remember it's because the CPU-Port isn't setup properly. However, John is working on a rewrite of the whole network subsystem. so yeah nobody can really help much with this.
Thank you for letting me know - I spent today fiddling with VLAN settings and tcpdump and came to the conclusion I was out of my depth.
I'll wait for John to work his magic...
Tim