@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...
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
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.
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
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.
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.
... 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.
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.
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 ...
/* 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.
Yeah, I know that blocktrron (not @ing to avoid notification) was working on this a few years back (check that original author date of Tue, 6 Dec 2022 18:14:21 -0500 (00:14 +0100)).
He mentioned using it for Freifunk, and that its biggest problem is the construction of the power supply for the mPCIe slots; the power supply is/was weak enough that modern Mediatek cards would brown-out, which was difficult to deal with as they were firmware driven.
I believe for a bootloader, he originally built and used a version of u-boot. He shared https://github.com/blocktrron/u-boot-msm/. Looks like that's been bumped recently.
I never attempted to build this u-boot. I know that this Freescale board boots by using the bootrom / eLBC (?) to bootstrap the U-boot loader process from NAND. I don't know how the RCW is configured by the SMD components on the board, but https://github.com/blocktrron/u-boot-msm/commit/15378bc9e0d483a15ae9ab8fe1e712e88308b17f clearly indicates a particular TEXT_BASE for u-boot. I haven't looked back, but again, clearly that's a solved problem.
In terms of getting this U-Boot on, considering it's a NAND BGA, I reckon that, unless the user has a JTAG device like the BDI2000 or BDI3000 and the knowledge required to use it to rewrite NAND (I never got that far https://github.com/Hurricos/openwrt/issues/21), the process must be to use the original exploit we've found to gain shell access, then manually replace u-boot from within the OEM Linux shell.
A problem for OpenWrt supportability is that U-boot replacements generally "should be" maintained in-tree (see all the Marvell devices). I will be the first to admit that I am unqualified, and that I don't want to bother David to ask to maintain the u-boot port under the OpenWrt libc / build system.
That said, the 460 / 560 series are nice APs. I can look back in my email, it's possible he gave me direct instructions for how to build and I just neglected it because I was (and still am) not a great developer :^)
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.