FR: mpc85xx: Support Ruckus R700

[Hurricos]

See https://forum.openwrt.org/t/create-firmware-for-ruckus-r700/133484

Checklist

• Booting
  • How does the OEM device boot?
    • Q: What's the output of help in u-boot?
      • FR: mpc85xx: Support Ruckus R700 #23 (comment)
    • Q: What's the output of printenv in u-boot? (please scrub MACs and serials, etc.)
      • [Where's the link?]
    • Sounds like from the above, we know the OEM device uses SPI flash -- not memory-mapped on this platform -- and so uses sf to start the SPI flash subsystem and copy stuff out of it into RAM before booting. This, combined with the absence of a bootcmd, strongly suggests we'll find the stock boot commands in the strings in the original flash dump. So:
    • TODO: Dump flash and strings | grep -we sf through it to find the scripts it runs on boot.
    • Do we know of other Ruckus boards that use u-boot? Are there special OpenWrt workarounds for this?
  • Device tree
    • TODO: We'll start by copying another P1010-like from under target/linux/mpc85xx/files/arch/powerpc/boot/dts on the main branch, and beginning to edit the partition list under {lbc:nor@0,0:partitions} (or equivalent -- there is more than one way to create a device tree that the kernel can use to find its rootfs.)
• Wireless
  • Calibration?
    • This board almost certainly uses on-flash calibration data because
      • TODO: Confirm the calibration data is in flash.
    • See https://github.com/rsa9000/atheepmgr for C code which can decode calibration data files.
      • In ath9k world, calibration data sits in a single 0x10000 page, at 0x1000 and 0x5000 for 2.4 and 5GHz, respectively.
      • In ath10k ... not so sure. Worth checking atheepmgr or (more importantly) other ports which must load calibration data to run the ath10k cards.

[lukejenkins]

u-boot help:

=> ?
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootid  - bootid  - set id of main boot image
bootlcl - bootlcl - boot a flash image
bootm   - boot application image from memory
bootnet - bootnet - boot a network image
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
cleardatafs- erase datafs flash partition
clearenv- erase u-boot environment flash partition
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
date    - get/set/reset date & time
echo    - echo args to console
editenv - edit environment variable
env     - environment handling commands
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fdt     - flattened device tree utility commands
go      - start application at address 'addr'
help    - print command description/usage
himem   - himem   - display high mem data, optional reset
i2c     - I2C sub-system
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
interrupts- enable or disable interrupts
irqinfo - print information about IRQs
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
md5     - md5     - calculate md5 sum of a flash image
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - display MMC info
mtest   - simple RAM read/write test
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
pci     - list and access PCI Configuration Space
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
reginfo - print register information
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
sata    - SATA sub system
saveenv - save environment variables to persistent storage
setenv  - set environment variables
setexpr - set environment variable as the result of eval expression
sf      - SPI flash sub-system
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true    - do nothing, successfully
updatebkup- update bkup image
updatemain- update main image
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version
wdoff   - wdoff   - disable h/w watchdog
=>

[lukejenkins]

MAC addresses anonymized with AA:BB:CC:DD: but all three addresses matched and then were 0,1, & 2.

=> printenv     
baudrate=115200
bootdelay=3
bootfile=uImage
consoledev=ttyS0
eth1addr=AA:BB:CC:DD:10:01
eth2addr=AA:BB:CC:DD:10:02
ethact=eTSEC1
ethaddr=AA:BB:CC:DD:10:00
fdtaddr=c00000
fdtfile=p1024rdb.dtb
hostname=unknown
imagefile=rcks_fw.bl7
ipaddr=10.0.0.1
loadaddr=1000000
netdev=eth0
ramboot=console=$consoledev,$baudrate $othbootargs; bootnet $ramdiskaddr $ramdiskfile
ramdiskaddr=2000000
ramdiskfile=vmlinux
rootpath=/opt/nfsroot
serverip=10.0.0.5
stderr=serial
stdin=serial
stdout=serial
uboot=u-boot.spi
updateuboot=tftpboot $loadaddr $uboot; sf probe 0; sf erase 0 $filesize; sf write $loadaddr 0 $filesize
Environment size: 654/8188 bytes
=> 

[Hurricos]

Great, thanks. I was looking in printenv for the bootcmd (not there), but outside of that, other configurable strings ... sounds like we can't reconfigure the boot chain, so we'll likely need to put our kernel image exactly where the old system put its image.

Edit: to be clear RE: boot chain: all u-boot devices run something when they 'autoboot'; sometimes they run run bootcmd, which takes the content of that variable and boots it. Others overwrite a bunch of variables before doing that, like the Aerohive HiveAP 330 does.

We can look through the u-boot binary and find what this one runs -- probably a hardcoded string -- given the use of sf you should strings the beginning of your dump (where u-boot lives, per the updateuboot env variable) and grep -w sf through it.

Let's keep working on the image backup. Once that's done, the next step IMO will be crafting a device tree.

[Hurricos]

RE: Ruckus boot chain, git log -p --grep Ruckus shows that @Leo-PL has touched a lot of Ruckus boards. He's only ported ath79 ones, but there's a common theme there that might be common here; from commit 0eebc6f:

    3. Set the "bootcmd" variable to disable the dual-boot feature of the
       system and ensure that uImage is loaded. This is critical step, and
       needs to be done only on initial installation.
    
       > setenv bootcmd "bootm 0xbf040000"
       > saveenv

It's possible the same fact (that setting the bootcmd disables the dual-boot feature) is true on this mpc85xx Ruckus board.

@lukejenkins, could you show us whether this section in the normal boot sequence changes if you setenv bootcmd "bootm sf probe 0"; saveenv; reset?

Hit Ctrl-c to stop autoboot:  0 
RKS Header: load_address=0x0
RKS Header: offset=0xa0, entry=0x0, len=10901340
Image loaded from 0--004d88bc
   Loading Device Tree to 00ff6000, end 00fff2f8 ... OK
Using P1024 RDB machine description

[lukejenkins]

Here are the results:

=> printenv
baudrate=115200
bootdelay=3
bootfile=uImage
consoledev=ttyS0
eth1addr=AA:BB:CC:DD:01
eth2addr=AA:BB:CC:DD:02
ethact=eTSEC1
ethaddr=AA:BB:CC:DD:00
fdtaddr=c00000
fdtfile=p1024rdb.dtb
hostname=unknown
imagefile=rcks_fw.bl7
ipaddr=10.0.0.1
loadaddr=1000000
netdev=eth0
ramboot=console=$consoledev,$baudrate $othbootargs; bootnet $ramdiskaddr $ramdiskfile
ramdiskaddr=2000000
ramdiskfile=vmlinux
rootpath=/opt/nfsroot
serverip=10.0.0.5
stderr=serial
stdin=serial
stdout=serial
uboot=u-boot.spi
updateuboot=tftpboot $loadaddr $uboot; sf probe 0; sf erase 0 $filesize; sf write $loadaddr 0 $fi

Environment size: 654/8188 bytes
=> setenv bootcmd "bootm sf probe 0"
=> printenv
baudrate=115200
bootcmd=bootm sf probe 0
bootdelay=3
bootfile=uImage
consoledev=ttyS0
eth1addr=AA:BB:CC:DD:01
eth2addr=AA:BB:CC:DD:02
ethact=eTSEC1
ethaddr=AA:BB:CC:DD:00
fdtaddr=c00000
fdtfile=p1024rdb.dtb
hostname=unknown
imagefile=rcks_fw.bl7
ipaddr=10.0.0.1
loadaddr=1000000
netdev=eth0
ramboot=console=$consoledev,$baudrate $othbootargs; bootnet $ramdiskaddr $ramdiskfile
ramdiskaddr=2000000
ramdiskfile=vmlinux
rootpath=/opt/nfsroot
serverip=10.0.0.5
stderr=serial
stdin=serial
stdout=serial
uboot=u-boot.spi
updateuboot=tftpboot $loadaddr $uboot; sf probe 0; sf erase 0 $filesize; sf write $loadaddr 0 $fi

Environment size: 681/8188 bytes
=> saveenv
Saving Environment to SPI Flash...
00000000: 01 02 20 4d 00    .. M.
SF: Detected S25FL512S with page size 512, total 64 MiB
Erasing SPI flash....Writing to SPI flash...done
=> 
=> 
=> reset

U-Boot 2010.12 (Sep 17 2013 - 11:13:52)
GD43 1.1.0.16 - built 11:13:59, Sep 17 2013

CPU:   P1011E, Version: 1.1, (0x80ed0011)
Core:  E500, Version: 5.1, (0x80212051)
Clock Configuration:
       CPU0:666.667 MHz, 
       CCB:333.333 MHz,
       DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:20.833 MHz
L1:    D-cache 32 kB enabled
       I-cache 32 kB enabled
Board: P1024RDB 
I2C:   ready
SPI:   ready
DRAM:  256 MiB (DDR2, 32-bit, CL=5, ECC off)
Top of RAM usable for U-Boot at: 0ff00000
Now running in RAM - U-Boot at: 0fe30000
L2:    256 KB enabled
MMC:  FSL_ESDHC: 0
00000000: 01 02 20 4d 00    .. M.
SF: Detected S25FL512S with page size 512, total 64 MiB
flash_reserved_offset=0x1fc0000 flash_end_reserved_bytes=0x40000
00000000: 01 02 20 4d 00    .. M.
SF: Detected S25FL512S with page size 512, total 64 MiB
board_configuration(0xfd2e240) @ 0x1fc0000
v54 mac addr:  2c c5 d3 09 db 43
PCIe1: Root Complex of mini PCIe SLOT, x1, regs @ 0xffe0a000
  01:00.0     - 168c:003c - Network controller
PCIe1: Bus 00 - 01
PCIe2: Root Complex of PCIe SLOT, x1, regs @ 0xffe09000
  03:00.0     - 168c:0033 - Network controller
PCIe2: Bus 02 - 03
In:    serial
Out:   serial
Err:   serial
Net:   eTSEC1: PHY is AR8035 PHY (4dd072)
eTSEC3: PHY is AR8035 PHY (4dd072)
eTSEC1, eTSEC3
No Himem Boot Script !!!
Found Boot Script ...
Hit Ctrl-c to stop autoboot:  0 
bootm - boot application image from memory

Usage:
bootm [addr [arg ...]]
    - boot application image stored in memory
        passing arguments 'arg ...'; when booting a Linux kernel,
        'arg' can be the address of an initrd image
        When booting a Linux kernel which requires a flat device-tree
        a third argument is required which is the address of the
        device-tree blob. To boot that kernel without an initrd image,
        use a '-' for the second argument. If you do not pass a third
        a bd_info struct will be passed instead

For the new multi component uImage format (FIT) addresses
        must be extened to include component or configuration unit name:
        addr:<subimg_uname> - direct component image specification
        addr#<conf_uname>   - configuration specification
        Use iminfo command to get the list of existing component
        images and configurations.

Sub-commands to do part of the bootm sequence.  The sub-commands must be
issued in the order below (it's ok to not issue all sub-commands):
        start [addr [arg ...]]
        loados  - load OS image
        ramdisk - relocate initrd, set env initrd_start/initrd_end
        fdt     - relocate flat device tree
        cmdline - OS specific command line processing/setup
        bdt     - OS specific bd_t processing
        prep    - OS specific prep before relocation or go
        go      - start OS
=> 

[Hurricos]

Great! So we can override the bootcmd.

I'd suggest you trace the remainder of the dump to understand what's in it -- in particular, where the u-boot binary and env start and stop, and where the calibration data is - if any.

You should be able to find the caldata location pretty easily. There'll be one for your ath9k card and one for your ath10k one.

Here's the caldata from a BSAP2030 - all QCA9880 caldatas are 0x844-long per atheepmgr:

# test.eep
RAhIcgIDAAJvAAAgAAAAAFUJAAhEDAgAAAAVAAAAdwAAAAAAAACYAABgAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgEgAgAAEREBABAAEAAQAAAAIAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAEkECQCZmQkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAYGBgAGBgYABgYGAAICAgACAgIAAgICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM0AAED/if8AAAAAAAAAAAAAAAAAAAAAAAAA
AAB5ZAAAAAAAAAAAAAAAAAAAAAAAAAAAeWQAAAAAAAAAAAAAAAAAAAAAAAAAAHlkAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwrHCO
rABwjqwAcI6sABwcHBwcHBwcHBwaGhwcGhocHBoaFBQUiERACIREAAAAFBQUiERACIREAAAAFBQU
iERACIREAAAAFBQUiERACIREAAAAFBQUiERACIREAAAAFBQUiERACIREAAAAERIVFxocQUJFR0pM
MTI1Nzo8AABwdZ2icHWdonB1naJ6f5OYcHWdonp/k5hwday4cHWnrHB1p6x6f52icHWnrHp/naJw
daescHWnrHB1p6x6f52icHWnrHp/naI8fDw8PHw8PDx8PDw8fDw8PHw8PDx8PDw8fDw8PHw8PDx8
PDw8fDw8PHw8PDx8PDw8fDw8PHw8PDx8PDw8fDw8PHw8PDx8PDwAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAGhweIBocHiAaHB4gGhweIBocHiAaHB4gGhweIBocHiAaHB4g
GhweIBocHiAaHB4gAABMWGiQqL3FzQ8TegCIABAUcACBABAUaQB7AAD6kgAOEmYAeAAQFHIAggAQ
FG4AfwAA+pIADhJkAHYAEBRzAIIAEBRuAH8AAPqRAA4SZwB4AA8TbAB3ABAUbgB9AAD6kgAOEmYA
dgAPE3EAewARFW8AgAAA+pEADxN2AH8ADxNqAHQAEhZwAH0AAPqQAA8TawB0ABAUbAB5ABIWaAB1
AAD6jwAQFG0AegARFXIAhQATF3QAfgAA+o8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAExYaIygvUxYaIygvUxYaIygvUxYaIyg
vSooJiQqKCYkKigmJCooJiQqKCYkKigmJBoaGu7OimasaMaKZhoaGu7OimasaMaKZhoaGu7Oimas
aMaKZhoaGu7OimasaMaKZhoaGu7OimasaMaKZhoaGu7OimasaMaKZhoaGsysaESKRqRoRBoaGsys
aESKRqRoRBoaGsysaESKRqRoRBoaGsysaESKRqRoRBoaGsysaESKRqRoRBoaGsysaESKRqRoRBoa
GsyKRiJoJIJGIhoaGsyKRiJoJIJGIhoaGsyKRiJoJIJGIhoaGsyKRiJoJIJGIhoaGsyKRiJoJIJG
IhoaGsyKRiJoJIJGIhAWGBkbHUBGSElLTTA2ODk7PQAATFxojLS5vc1MXGiMtLm9zU5eZo6uv8cA
UmKSosMAAP9MXGCMtLi9zU5eZo6utr/HTFhcaIyQsLRMWFxojJCwtE5WXmaOlqauUmKSogAAAABM
WFxojJCwtE5WXmaOlqauTFxgjLS4vc1MXGCMtLi9zU5eZo6utr/HUmKSorLDAABMXGCMtLi9zU5e
Zo6utr/HSlgYWFgYZCJKWBhYWBhkIlJgFlocJCQACAgGBhwAADx8PHx8PDx8PHw8PHw8PDw8fDx8
PDx8PDx8PHw8PHw8PDw8PDw8fDw8PDw8PAAAAAB8PHw8PHw8PDw8PDw8fDw8fDx8fDw8fDx8PHx8
PDx8PHw8PHw8PDw8PDw8PDw8AAB8PHx8PDx8PHw8PHw8PDw8AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcmKCocJiosKC0xMyUw
NTUoMDE1LjA3NyQzNjcsNDg4FyYoKhwmKiwoLTEzJTA1NSgwMTUuMDc3JDM2Nyw0ODgXJigqHCYq
LCgtMTMlMDU1KDAxNS4wNzckMzY3LDQ4OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA==

It contains a nice string:

[mkennedy@genie atheepmgr]$ strings -td full.bin | grep ABEGJL12 
66867992 ABEGJL1257:<
[mkennedy@genie atheepmgr]$ strings -td test.eep | grep ABEGJL12 
    792 ABEGJL1257:<

... so the full bin has a QCA9880-compatible caldata section at exactly 66867992-792 = 0x3FC5000.

Confirming atheepmgr likes it:

[mkennedy@genie atheepmgr]$ ./atheepmgr -t 9880 dump -F test.eep | head

.----------------------.
| EEPROM Base Header   |
'----------------------'

Length                         : 0x0844
Checksum                       : 0x7248
EEP Version                    : 2
Template Version               : 3
MacAddress                     : 00:02:6F:00:00:20

When you find your calibration data offsets, they need to be inserted into a new .dts file under mpc85xx so that the ath9k and ath10k drivers can load their calibration data when they start.

For formatting that device-tree notation, git log is your friend here.

grep -lr . -we calibration --include='*.dts' -C 10 | xargs grep -le ath10k -C 10 | xargs git log gives a lot -- specifically RE: QCA9880/9890, looks like commits 590d1fd and 0ffbef9 both implement ath10k caldata sections.