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.
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 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 : 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
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:
... 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.
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.
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 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: 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/
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: https://fccid.io/RTP-MRLBB1003S
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.
I can help to test the u-boot.
I really don't want to bother him with it, so I won't @ him, but I did see in blocktrron's staging tree a commit which supposedly provides support for the MSM460: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commitdiff;h=6644a444807b7762fd5397890a8c6abacb3608cb
In particular, I notice that the device tree specifies a hint for the
chosen entry required to get this board to boot:
/* Needed for initramfs */
bootargs-override = "console=ttyS0,115200 ubi.mtd=3,2048";
If that works, fantastic. He's also using a FIT image in the same commit, which I doubt the stock U-Boot supports, but ...
As I've found over the last year from his advice, I'm guessing there only reason the kernel doesn't boot is some early boot issue that can be solved by being more hands-on during the firmware interface between U-Boot and Linux.