OpenWrt support for HP Prototype Access Point?

Hmmm...I tried running setenv bootargs ro earlyprintk, which printenv verified was successful, but every time I try it and try booting the image it always says

Kernel arg: 'ro'

Well that’s a bit odd. Can you post another printenv output?

Try just having earlyprintk and no other bootargs, any change?

=> printenv
bootargs=ro
bootcmd=setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs; tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
bootdelay=3
baudrate=115200
loads_echo=1
rootpath=/opt/nfsroot
hostname=NANAIMO
bootfile=uImage
loadaddr=1000000
netdev=eth0
uboot=u-boot.bin
loadaddr=1000000
bootfile=uImage
tftpflash=tftpboot $loadaddr $uboot; protect off 0x01001000 +$filesize; erase 0x01001000 +$filesize; cp.b $loadaddr 0x01001000 $filesize; protect on 0x01001000 +$filesize; cmp.b $loadaddr 0x01001000 $filesize
consoledev=ttyS0
ramdiskaddr=2000000
ramdiskfile=rootfs.ext2.gz.uboot
fdtaddr=c00000
fdtfile=p2020rdb.dtb
bdev=sda1
jffs2nand=mtdblock9
nandbootaddr=200000
nandfdtaddr=100000
nandimgsize=400000
nandfdtsize=100000
usb_phy_type=ulpi
vscfw_addr=ef000000
othbootargs=ramdisk_size=700000 cache-sram-size=0x10000
nandboot=setenv bootargs root=/dev/$jffs2nand rw rootfstype=jffs2 console=$consoledev,$baudrate $othbootargs;nand read 2000000 $nandbootaddr $nandimgsize;nand read 3000000 $nandfdtaddr $nandfdtsize;bootm 2000000 - 3000000;
recreate_bbt=nandbbx scanbbt; nandbbx trashsb; reset
ethaddr=08:2e:5f:ee:f0:f6
ethact=eTSEC1
ipaddr=192.168.1.13
serverip=192.168.1.158

Environment size: 1734/131068 bytes
=> setenv bootargs earlyprintk
=> printenv
bootcmd=setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs; tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
bootdelay=3
baudrate=115200
loads_echo=1
rootpath=/opt/nfsroot
hostname=NANAIMO
bootfile=uImage
loadaddr=1000000
netdev=eth0
uboot=u-boot.bin
loadaddr=1000000
bootfile=uImage
tftpflash=tftpboot $loadaddr $uboot; protect off 0x01001000 +$filesize; erase 0x01001000 +$filesize; cp.b $loadaddr 0x01001000 $filesize; protect on 0x01001000 +$filesize; cmp.b $loadaddr 0x01001000 $filesize
consoledev=ttyS0
ramdiskaddr=2000000
ramdiskfile=rootfs.ext2.gz.uboot
fdtaddr=c00000
fdtfile=p2020rdb.dtb
bdev=sda1
jffs2nand=mtdblock9
nandbootaddr=200000
nandfdtaddr=100000
nandimgsize=400000
nandfdtsize=100000
usb_phy_type=ulpi
vscfw_addr=ef000000
othbootargs=ramdisk_size=700000 cache-sram-size=0x10000
nandboot=setenv bootargs root=/dev/$jffs2nand rw rootfstype=jffs2 console=$consoledev,$baudrate $othbootargs;nand read 2000000 $nandbootaddr $nandimgsize;nand read 3000000 $nandfdtaddr $nandfdtsize;bootm 2000000 - 3000000;
recreate_bbt=nandbbx scanbbt; nandbbx trashsb; reset
ethaddr=08:2e:5f:ee:f0:f6
ethact=eTSEC1
ipaddr=192.168.1.13
serverip=192.168.1.158
bootargs=earlyprintk

Environment size: 1743/131068 bytes
=> tftpboot 0x1000000 openwrt-21.02.1-mpc85xx-p1020-aerohive_hiveap-330-initramfs-kernel.bin
eTSEC1: Link up, full duplex, 100 Mbps
Using eTSEC1 device
TFTP from server 192.168.1.158; our IP address is 192.168.1.13
Filename 'openwrt-21.02.1-mpc85xx-p1020-aerohive_hiveap-330-initramfs-kernel.bin'.
Load address: 0x1000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ############################
done
Bytes transferred = 11122784 (a9b860 hex)
=> tftpboot 0x6000000 openwrt-21.02.1-mpc85xx-p1020-aerohive_hiveap-330-squashfs-fdt.bin
Using eTSEC1 device
TFTP from server 192.168.1.158; our IP address is 192.168.1.13
Filename 'openwrt-21.02.1-mpc85xx-p1020-aerohive_hiveap-330-squashfs-fdt.bin'.
Load address: 0x6000000
Loading: ###
done
Bytes transferred = 11446 (2cb6 hex)
=> bootm 0x1000000 - 0x6000000;
read_vblock 6
Kernel arg: 'ro'
## Booting image at 01000000 ...
   Image Name:   POWERPC OpenWrt
   Image Type:   PowerPC Linux Kernel Image (uncompressed)
   Data Size:    11122720 Bytes = 10.6 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

I did find something interesting in the help.

colub   - colub   - colubris specific commands

which then brings up

colub - colub   - colubris specific commands


Usage:
colub - colubris specific commands

        colub bid FNM          (Burn bid into flash blocks 0 and last block, page 31)
        colub cache [d|i|b [on|off]] (Display or set 'd'ata, 'i'nstr or 'b'oth cache)
        colub colnet           (Enter Colubris Boot mode for debugging)
        colub cpu [CPUTYPE]    (Display or change the cputype in the BID)
        colub dump_bid         (Dump the BID)
        colub factory          (Reset factory defaults and boot)
        colub fipsoff          (Turn fips mode off)
        colub flash_display [BLK] (Display NAND flash BLK)
        colub flash_erase [BEGBLK [ENDBLK]] (Erase NAND flash blocks)
        colub flash_test [BEGPG [ENDPG]] (Test NAND flash)
        colub hwflag [VAL]     (Display or change the hw flag in the BID)
        colub kbackup [ADDRESS]  (TFTP to address ADDRESS and save the Kozio diags at block 15)
        colub krun [ADDRESS]  (Load from block 15 into address ADDRESS and run the Kozio diags)
        colub kozio [ADDRESS]  (TFTP to address ADDRESS and run the Kozio diag)
        colub led_off [LEDNUM] (Turn off specific leds)
        colub led_on  [LEDNUM] (Turn on specific leds)
        colub led_on_off       (Turn on then off all leds)
        colub led_test         (Test led operation)
        colub product [PRODUCT] (Display or change the product id in the BID)
        colub reset_test       (Test reset button)
        colub speed [auto|10|100|1000 [auto|full|half]] (Set ethernet speed and duplexity)
        colub update [FNM]     (Update boot code)
        colub phy_dump     (Dump all PHY registers)
        colub phy_regread [offset]  (Read a PHY register by specifying offset in decimal)
        colub phy_regwrite [offset [value]]  (Write to PHY register by specifying offset in decimal and value in hex)

some of the commands that showed any information

=> colub cpu
CPU Type is currently Unknown cpu type (18)
=> colub dump_bid
CPU Type            : 18
Design Id           : 52 (Unknown product (52))
MAC Address         : 08:2e:5f:ee:f0:f6
Base Clock Speed    : 64000000
Serial Number       : TW2ZG2W101
Date Code           : 4625
Board Assembly      : ZZ-ZZ-ZZZZ-ZZ
Linux Startup       : ro
Country Code        : 124 (Read Write)
Hardware Flag       : 80000000
Feature Code        : 2056
OEM Code            : 00
=> colub hwflag
Current HW Flag is 0x80000000
=> colub product
Product is currently Unknown product (52)
=> colub phy_dump
Dumping PHY registers from 0 to 32
[00-03]:1140 7969 0141 0e90
[04-07]:01e1 4de1 0007 2801
[08-11]:447a 0e00 4000 0000
[12-15]:0000 0000 0000 3000
[16-19]:3060 7c08 0000 dc48
[20-23]:0020 0000 0000 0000
[24-27]:0000 0000 0040 0000
[28-31]:0000 0005 0000 0000

Hmmm, well that's not positive. With the kernel not starting at all there are no clues where to go next.

Perhaps extract all the mtds from the flash via uboot and see if there's a working fdt in there (maybe not as it doesn't boot + appears the developers were booting from usb).

And try the images mentioned above for ap3825i and go through the steps used in that thread to bring the device up.

Images here;
https://downloads.laboratoryb.org/releases/snapshot/targets/mpc85xx/p1020/

Hey @kb1sph,

Could you give me an FCC ID of your device, or if not, tear it down a bit to see if you can get us some images of the board? I'd like to see if I can get one myself.

Pretty much all P1020E APs are going to be the same with some quirks: NXP's P1020WLAN development board was pretty popular. All we'll really need to figure out are the U-boot quirks, which are things like:

  • what U-boot is doing to initialize processors
  • how it is relocating the device tree blob (dtb, same thing as an fdt)
  • how it is manipulating the device tree blob

When you say "HP Apache Prototype", I'm thinking "Aruba". Does your device look like any of the Aruba series?

Another thing, @kb1sph : feel free to hop onto the OFTC IRC channel (#openwrt-devel) for OpenWrt and ping me; I'm @hurricos there. I'm almost certain I'll be able to help you port, just trying to figure out what it is you're porting (I'm unable to actually view your OneDrive images; you may want to try https://paste.c-net.org.

2 Likes

Is this your motherboard?: https://fccid.io/RTP-MRLBB1003S/Internal-Photos/Main-Assembly-1386678.pdf

@jdwl1o1, I'm not sure how to go about extracting the mtds from the flash. I can do a read on the nand, or the eeprom, but all it does it show it in the terminal. Short of copying and pasting all the hex code into a hex editor, I'm not really sure how to go about this. I did try the images for that ap, but they too just give me the error Boot: Invalid image header: bad magic and some of the commands don't seem to work right. For example...

=> interrupts off; bootm start 0x2000000; bootm loados; bootm ramdisk; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go
read_vblock 6
Kernel arg: 'ro'
## Booting image at 00000000 ...
Boot: Invalid image header: bad magic
read_vblock 6
Kernel arg: 'ro'
## Booting image at 00000000 ...
Boot: Invalid image header: bad magic
read_vblock 6
Kernel arg: 'ro'
## Booting image at 00000000 ...
Boot: Invalid image header: bad magic

I feel like my biggest problem is that the u-boot on here is not a normal u-boot. Or maybe a really old u-boot?

@hurricos, that does look similar. I didn't realize that my link wasn't working and fixed it. Somehow the folder got deleted off of my OneDrive, but it was in the recycle bin and I restored it.

There is no FCC ID on this that I can find.

IRC...I don't think I've been on IRC in probably over 10 years! IS mIRC still the popular app? I might have to get in there when I have a moment.

Here's what I can tell you about the access point.

PCI Devices

=> pci 0
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
00.00.00   0x1957     0x0100     Processor               0x20
=> pci 1
Scanning PCI devices on bus 1
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
01.00.00   0x1957     0x0100     Processor               0x20
=> pci 2
Scanning PCI devices on bus 2
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
02.00.00   0x168c     0x0033     Network controller      0x80

EEPROM is an i2c chip at address 0x56, most likely MB85RC I2C FRAM
NAND is Micron MT29F1G08ABBDA

Hey, good question.

I would create a simple ppc root file system on a usb stick and change the uboot variables to have the kernel on the flash boot it. Search for ppcspe rootfs online if you’re keen to give that a go.

However, you can extract the flash contents directly from uboot via serial, here’s an old thread with the steps;
https://forum.archive.openwrt.org/viewtopic.php?id=57088&p=1

As for uboot, 2012 is old but it’s not like uboot changes that much overtime. More important than age is what the developers did to uboot for this application. If it is crippled, or will only boot their intended kernel then that’s a pain.
It’s not like they have enforced secure boot or anything, which you can see with newer uboots

Your OneDrive link above still isn't working for me. Would you mind uploading your images to a different site?

It certainly looks like bootm go is behaving differently than it should.

Also, notice the OEM bootcmd. The board is very clearly supposed to boot from USB:

bootcmd=setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr
:
bdev=/dev/sda1

If I can get my hands onto one of these devices, I can try porting it.

I wish I had bought more at the time. I could have sent you one. When I came across these at the ham-fest, they had probably at least 10 of them. i just grabbed one for $10 to play with it. They are very interesting because they have the GPS as well, which seems to be integrated into the wi-fi card.

Also, I'm pretty sure this is a modified (cut down) version of u-boot. When I do "run bootcmd" I get this.

=> run bootcmd
Unknown command 'usb' - try 'help'
Unknown command 'ext2load' - try 'help'
Unknown command 'ext2load' - try 'help'
read_vblock 6
Kernel arg: 'ro'
## Booting image at 01000000 ...
Boot: Invalid image header: bad magic

Upload the photos elsewhere :laughing:

Did you get my messages on IRC?

Sadly, I think something got fried this morning. I took it apart more to get under the cover over the chips and identify things. And, I left it sitting and someone thought they would be helpful putting it back together. Unfortunately, the serial and network cables were reversed and I didn't realize it. I was using a POE injector instead of hooking it up to my POE switch, and it ended up putting 48v into the serial connection. Now I do not see any lights come on when I plug it in (the correct way) and there is no serial communications. It has a max322e (MP223EC) chip and I was hoping that maybe I just fried that, but where none of the lights are coming on that were before, I fear the voltage my have got through to the processor. The POE chip still works as it negotiates with my switch and turns on the power when I plug it into my POE switch, but the board doesn't seem to attempt to boot.

I'm tempted to get a cheap MSM466 off eBay. Near as I can tell, this is exactly the same as the MSM466-R (I believe the R only means that it comes in the outdoor case). I think the only difference, besides the silkscreen having different numbers, is the wireless card and the GPS antenna.




I'm tempted to get a cheap MSM466 off eBay. Near as I can tell, this is exactly the same as the MSM466-R (I believe the R only means that it comes in the outdoor case)

Correct! If you'd be willing to purchase one for me as well (looks like they go for about $20 with shipping) I will gladly give you my mailing address and help you port.

Back side of the wireless board. The giant block is just a heatsink, but under the small cover is the GPS.



Great.

Some extra info you fed me over IRC:

Board footprint

... Center-to-center on the screw holes ... longest side of board is aprox 148mm, short side it 124mm, diagonal is 193mm had a tape measure with metric.

Trimble GPS IC

The GPS module with the label 66650-19 in your image up here is a ICM-SMT_40MHZ, likely the same module referred to by this very insecure link to an .lbr file (likely a conf file of sorts). Unfortunately, the USB on the mini-PCIe interface isn't connected (pins 36 and 38), so I don't know how the GPS connects.

USB

Not sure where or if it wires out on this board, but here is the full P1020 spec sheet which shows the USB pinout. On page 72 of that spec sheet, it mentions that P1020 has two USB ports; one of them is used for eLBC (executing from flash in-place on early boot). It's possible the environment variables only show mentions of loading files from USB because the engineers never bothered to clean it up.

Oh wow.

So this is almost certainly a prototype TDMA access point. The GPS synchronization receiver is the giveaway - that Trimble module is pretty much industry-standard for around the time period when this would've been designed/assembled.

Probably the best-known implementation is Ubiquiti's AirMax system (only recently gained GPS sync), shortly followed by Cambium ePMP and Mimosa's various PTMP solutions. You take a standard WiFi chipset, and write your own custom firmware/MAC for it that uses TDMA instead of CSMA/etc to divide up bandwidth between clients. GPS synchronization for the access-point side lets you shove multiple APs on the same tower, or on neighboring towers, and not have to deal with as much co-channel interference since the APs will all transmit at the same time.

The oldest system I know of was the Trilliant SkyPilot, waaaaaay back in 2005 or so. Self-configuring, self-healing, GPS-synchronized multi-wired-uplink mesh wireless network equipment based off commoddity 802.11b/g PHYs with a custom MAC layer doing TDMA. You could get a solid 10Mbps out of a two-hop link if you were really lucky. A company I used to work for set up a couple of SkyPilot networks in regional parts of Australia, one of which is still running today - almost 15 years later.

The fact that this exists at all is very interesting; I had no idea HP were considering joining in the fun of the late-2000s TDMA wifi "wars". Probably built it for a contract they didn't win, or decided the market was too small.

I highly doubt you'll have any luck at all getting that wireless card to work, but please, please, please dump the contents of the NAND on the thing and upload it somewhere. If the design never made it to production, you may well have the last one of those devices left in existence.

[Fake edit]: Ah, I've just noticed the part where the board's been damaged :confused: with any luck the NAND itself is still okay... I would love to get that board off you (or just the NAND chip) to dump it, if you'd be vaguely interested.

I doubt there's anything fancy about the board itself, just the radio card and the software.

3 Likes

I have begun a tree here: https://github.com/Hurricos/openwrt/tree/add_hp_msm466

Downloads should be available here in 30 minutes or so: https://downloads.laboratoryb.org/releases/snapshot/targets/mpc85xx/p1020/