OpenWrt support for HP Prototype Access Point?

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;

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


Is this your motherboard?:

@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;

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

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.


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.


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.


I have begun a tree here:

Downloads should be available here in 30 minutes or so:

Sorry, I haven't checked the thread in a while. Honestly, I'm not sure if the nand would be of any help. It seemed like someone had maybe attempted a firmware update that failed or something before I got it. I couldn't get it to boot up. If you are interested in it though, I could probably send it to you if you're in the US.

Because of the behavior of the bootloader -- even bootm start performs the whole boot process on its own -- it's likely a u-boot replacement will be necessary.

That is, unless we can use the "bidio" to tell U-boot how to perform the boot process. Perhaps the addresses of the kernel, dtb and rootfs are defined there somehow? It's very clear that bidio is parsed, because its values determine whether or not u-boot interacts with the secondary serial console.

I will send out a letter to Hewlett Packard this week and see if they respond to snail-mail requests for GPL sources for their U-boot. I'll also look closer at the bidio file to see whether it contains any sort of encoding of the address scheme ...

Because I saw them, and because they were too well-priced to avoid, I purchased 7 of these:

So far as I can tell (I haven't received them yet) they are very similar to the prototype described above, but probably without GPS. We'll find out.