I get that. Forgive me as I am still learning, but this image I used looks like it's 2 part setup when upgrading from the factory firmware of the HiveAP. There is the initramfs-kernel, and then there is the squashfs-fdt.
I was just thinking that the freezing had something to do with missing the squashfs. Or would it be because this particular kernel, while it seems to check out and not give the bad magic number error, is not exactly built for whatever chips are on this board?
Also, for anybody with u-boot experience, what is the difference (not physical, but in the u-boot scenario) between nand and eeprom? I guess, not knowing any better, that I thought it would have one or the other. Or maybe that eeprom would just for variable storage while the firmware would be stored in the nand. I seem to have an eeprom chip at i2c address 0x56, but then there is also the nand chip. Reading portions of both of them, some of the content has the same hex value, but at the beginning of the eeprom I see this. (read from eeprom into ram at 0x1000000)
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
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.
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.
@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.