I don't have many mpcie cards I can test with in my MSM466 to try to replicate your problem. I can try digging out a card eventually but I'm currently working on rtl838x stuff at the moment.
Getting a 560 to try to replicate your problem is probably more than 2-3 weeks away at least for me. I'm going to prioritise getting an rtl8393 platform.
I've read the patches for the u-boot implementation you flash for MSM460. Doesn't look like they changed anything regarding PCI initalisation over what was for p1020 RDB. the pci command in uboot only outputs this for me on my msm466. My only other experience (Cavium cn5020) I've had it also spit out the wifi cards.
=> pci
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
_____________________________________________________________
00.00.00 0x1957 0x0100 Processor 0x20
=>
I can't help with u-boot stuff really. Don't have a way to fix the bootloader if i screw it up. Can't test a bootloader by loading into sdram haha. I have some other JTAG capable probes but i don't know the pins nor have the devices I've seen talked about for powerpc? (bdi2000 / bdi3000?). I only have one test AP for MSM466, the other four are going to be deployed. My experience with powerpc, mips jtag etc approximates zero. Only done ARM SWD.
Did you dump the flash before you put openwrt on this thing? I dumped as many partitions as I could via the factory shell and curl / FTP. Verify the different partitions didn't get damaged?
Are the mac addresses being set properly? Or is it you never get the cards to come up / driver load at all?
Can't help you with power converter stuff until I can try to replicate your problem. I guess we can compare the converters in MSM466/MSM460 vs HP 560 if the board numbers are different. I'd have to dig out my oscilloscopes to investigate any transient behaviour.
So it seems that the issue starts with where it reads the mac address from.
HP MSM460 the mac is in colubris-bid at 0x1f9bd
HPE 560 the mac is in colubris-bid at 0x1f9d2 OR 0x1f9bd (this might apply to 460 as well but am not sure) we need to better understand the memory location.
I think we need to better understand the bid before we do this, since on MSM560 (at least) I found 2 version of BID (one having command line option just "ro" the other one "ro console=ttyS0,115200" this would change the location from where the mac address is read (before "ro" (at location 0x1F87C) there is the length of the actual command line ("ro"=02, "ro console=ttyS0,115200"=17)) and this will change the location of the mac from 0x1f9bd (0x1f9bb + 0x02) to 0x1f9d2 (0x1f9bb + 17).
Maybe this applies to 460 as well
I think we need to update how the device mac is read. Anyone up to it? (in the next major version the MAC address won't be set in userspace anymore)
OK so we have the MAC in DTS change as a PR. Looks like you're commenting on that too?
So you're saying that the mac address location changes depending on the command line options for factory? I recall that you can change settings in factory firmware regarding whether you want a serial console or not, as well as what speed you're after?
From what I understand, U-Boot finds the WLAN mac address too?
Is your unit finding the right mac address in u-boot?
There's a backup Colubris BID starting at 0x3f800 right? I guess we check if that changes too?
I'd have to do testing on another MSM466.
I can change the DTS and get you a patch/build for the 560. But I wouldn't be able to test it.
That is exactly one version on how to have a bid with different offset for wan mac; but there are others as well. Thing is there is no way in OpenWRT to revert to a factory default bid. Maybe having a factory reset tool in openwrt would also be ok-ish (that way the offsets will always be correct).
Use the curl method after getting a shell to dump the flash to an external FTP server.
Open it up and obtain photos of the front and backside of the board, the radios etc. What's the CPU, nand flash, memory chip etc. i.e. to make sure the existing DTS and u-boot will work.
What's the FCC ID? Can i look this up and get more data that way?
The unsafe way I guess would be (attempt to) flash an MSM460 bootloader on it and see if you brick it =P Per the above conversations regarding the HP 560, you might have issues with the colubris bid layout but that would at least get you a bootloader that you can load arbitrary code on to then get the board support the rest of the way.
Edit: datasheet says cpu 800mhz same ram and flash? One part says it's a 2 stream radio rather than 3, but has the same antenna configuration? Didn't find a teardown nor FCC images.
the only FCC ID I could find is the same as hurricos posted in April of 2022
I opened one of my MSM430s up and it looks basically the same
I played around with it a bit and was about to flash the modded bidio,
but instead decided to yolo it and flashed the msm460 image according to blocktrron's guide
and it worked!
flash and wait for the rapid LED pattern
reboot
both radios are deteced and can broadcast on 5 or 2.4 GHz
it has 74MiB free disk space, so plenty enough to install some additional packages
so far I cannot find an issue
serial output during TFTP flash
NAND boot...
Second program loader running in sram...transfering control
WARNING: Calling __hwconfig without a buffer and before environment is ready
WARNING: Calling __hwconfig without a buffer and before environment is ready
Tertiary program loader running in sram...transfering control
U-Boot 2014.04-00001-g4d68b09daa (May 28 2024 - 22:56:30)
CPU0: P1020E, Version: 1.1, (0x80ec0011)
Core: e500, Version: 5.1, (0x80212051)
Clock Configuration:
CPU0:800 MHz, CPU1:800 MHz,
CCB:400 MHz,
DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:50 MHz
L1: D-cache 32 KiB enabled
I-cache 32 KiB enabled
Board: HP MSM460
I2C: ready
SPI: ready
DRAM: 256 MiB (DDR3, 32-bit, CL=5, ECC off)
L2: 256 KiB already enabled
NAND: 128 MiB
*** Warning - bad CRC, using default environment
PCIe1: Root Complex of mini PCIe SLOT, x1 gen1, regs @ 0xffe0a000
01:00.0 - 168c:0030 - Network controller
PCIe1: Bus 00 - 01
PCIe2: Root Complex of PCIe SLOT, x1 gen1, regs @ 0xffe09000
03:00.0 - 168c:0030 - Network controller
PCIe2: Bus 02 - 03
In: serial
Out: serial
Err: serial
Net: eTSEC1 [PRIME]
Hewlett-Packard MSM460 Pre-Boot
NAND read: device 0 offset 0xc0000, size 0x40000
262144 bytes read: OK
Ethernet MAC address: 84:34:97:<redacted>
WLAN MAC address: 38:ea:a7:<redacted>
Device IP-Address: 192.168.1.107
Press reset button to enter recovery mode...
Press reset button for 5 seconds.
Reset button not pressed, continuing boot...
Hit any key to stop autoboot: 3 ... 2 ... 1 ... 0
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
UBI init error 22
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 192.168.1.66; our IP address is 192.168.1.107
Filename 'msm460-factory.bin'.
Load address: 0x4000000
Loading: *#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
####################################################
6.1 MiB/s
done
Bytes transferred = 8388608 (800000 hex)
NAND erase.part: device 0 offset 0x500000, size 0x5f00000
Erasing at 0x500000 -- 0% complete.
Erasing at 0x5e0000 -- 1% complete.
Erasing at 0x6e0000 -- 2% complete.
Erasing at 0x7c0000 -- 3% complete.
Erasing at 0x8c0000 -- 4% complete.
Erasing at 0x9a0000 -- 5% complete.
Erasing at 0xaa0000 -- 6% complete.
Erasing at 0xba0000 -- 7% complete.
Erasing at 0xc80000 -- 8% complete.
Erasing at 0xd80000 -- 9% complete.
Erasing at 0xe60000 -- 10% complete.
Erasing at 0xf60000 -- 11% complete.
Erasing at 0x1060000 -- 12% complete.
Erasing at 0x1140000 -- 13% complete.
Erasing at 0x1240000 -- 14% complete.
Erasing at 0x1320000 -- 15% complete.
Erasing at 0x1420000 -- 16% complete.
Erasing at 0x1520000 -- 17% complete.
Erasing at 0x1600000 -- 18% complete.
Erasing at 0x1700000 -- 19% complete.
Erasing at 0x17e0000 -- 20% complete.
Erasing at 0x18e0000 -- 21% complete.
Erasing at 0x19e0000 -- 22% complete.
Erasing at 0x1ac0000 -- 23% complete.
Erasing at 0x1bc0000 -- 24% complete.
Erasing at 0x1ca0000 -- 25% complete.
Erasing at 0x1da0000 -- 26% complete.
Erasing at 0x1ea0000 -- 27% complete.
Erasing at 0x1f80000 -- 28% complete.
Erasing at 0x2080000 -- 29% complete.
Erasing at 0x2160000 -- 30% complete.
Erasing at 0x2260000 -- 31% complete.
Erasing at 0x2360000 -- 32% complete.
Erasing at 0x2440000 -- 33% complete.
Erasing at 0x2540000 -- 34% complete.
Erasing at 0x2620000 -- 35% complete.
Erasing at 0x2720000 -- 36% complete.
Erasing at 0x2820000 -- 37% complete.
Erasing at 0x2900000 -- 38% complete.
Erasing at 0x2a00000 -- 39% complete.
Erasing at 0x2ae0000 -- 40% complete.
Erasing at 0x2be0000 -- 41% complete.
Erasing at 0x2ce0000 -- 42% complete.
Erasing at 0x2dc0000 -- 43% complete.
Erasing at 0x2ec0000 -- 44% complete.
Erasing at 0x2fa0000 -- 45% complete.
Erasing at 0x30a0000 -- 46% complete.
Erasing at 0x31a0000 -- 47% complete.
Erasing at 0x3280000 -- 48% complete.
Erasing at 0x3380000 -- 49% complete.
Erasing at 0x3460000 -- 50% complete.
Erasing at 0x3560000 -- 51% complete.
Erasing at 0x3660000 -- 52% complete.
Erasing at 0x3740000 -- 53% complete.
Erasing at 0x3840000 -- 54% complete.
Erasing at 0x3920000 -- 55% complete.
Erasing at 0x3a20000 -- 56% complete.
Erasing at 0x3b20000 -- 57% complete.
Erasing at 0x3c00000 -- 58% complete.
Erasing at 0x3d00000 -- 59% complete.
Erasing at 0x3de0000 -- 60% complete.
Erasing at 0x3ee0000 -- 61% complete.
Erasing at 0x3fe0000 -- 62% complete.
Erasing at 0x40c0000 -- 63% complete.
Erasing at 0x41c0000 -- 64% complete.
Erasing at 0x42a0000 -- 65% complete.
Erasing at 0x43a0000 -- 66% complete.
Erasing at 0x44a0000 -- 67% complete.
Erasing at 0x4580000 -- 68% complete.
Erasing at 0x4680000 -- 69% complete.
Erasing at 0x4760000 -- 70% complete.
Erasing at 0x4860000 -- 71% complete.
Erasing at 0x4960000 -- 72% complete.
Erasing at 0x4a40000 -- 73% complete.
Erasing at 0x4b40000 -- 74% complete.
Erasing at 0x4c20000 -- 75% complete.
Erasing at 0x4d20000 -- 76% complete.
Erasing at 0x4e20000 -- 77% complete.
Erasing at 0x4f00000 -- 78% complete.
Erasing at 0x5000000 -- 79% complete.
Erasing at 0x50e0000 -- 80% complete.
Erasing at 0x51e0000 -- 81% complete.
Erasing at 0x52e0000 -- 82% complete.
Erasing at 0x53c0000 -- 83% complete.
Erasing at 0x54c0000 -- 84% complete.
Erasing at 0x55a0000 -- 85% complete.
Erasing at 0x56a0000 -- 86% complete.
Erasing at 0x57a0000 -- 87% complete.
Erasing at 0x5880000 -- 88% complete.
Erasing at 0x5980000 -- 89% complete.
Erasing at 0x5a60000 -- 90% complete.
Erasing at 0x5b60000 -- 91% complete.
Erasing at 0x5c60000 -- 92% complete.
Erasing at 0x5d40000 -- 93% complete.
Erasing at 0x5e40000 -- 94% complete.
Erasing at 0x5f20000 -- 95% complete.
Erasing at 0x6020000 -- 96% complete.
Erasing at 0x6120000 -- 97% complete.
Erasing at 0x6200000 -- 98% complete.
Erasing at 0x6300000 -- 99% complete.
Erasing at 0x63e0000 -- 100% complete.
OK
NAND write: device 0 offset 0x500000, size 0x800000
8388608 bytes written: OK
here is a qucik BID parser that I have put together (it should work on all models).
maybe it helps
Also the bid is the "same" on 460/560 (that I have tested myself). Also openwrt works on 560 with the new uboot
Bid id 2 and 40 are the mac addresses (lan and wifi). This bid parser might work on 422 as well
#!/usr/bin/env python3
def file_read(filename):
with open(filename, mode="rb") as f:
return bytes(f.read())
return None
ba = bytearray(file_read('dd_bid_dump.bin'))
cbi = ba.index(b"Colubris_BID_$$$")
i = cbi + 24
func = 0
fdata = {}
while i < len(ba):
func = ba[i]
if func == 255:
break
i += 1
length = ba[i]
i += 1
data = ba[i:i+length]
data = bytes(data)
if func in [40, 2]:
data = data.hex()
if func in [9, 14, 17, 13, 39]:
data = '"'+ data.decode('latin1') +'"'
fdata[str(func)] = {'len': length, 'data': data, 'off': i}
i += length
for i in fdata.keys():
print(f"BID_id: {i} | Offset: {fdata[i]['off']} | Data: {fdata[i]['data']}")
OK so thanks for confirming the radios, board numbers are identical between MSM430/MSM460/MSM466?
How is your radio power output?
I'm hoping you can have a look at the colubris BID partition and ensure there aren't any major changes? The product name should be somewhere in there too.
We know from @blocktrron directly that for whatever reason, the mPCIe slots on this board have hard power limits -- with transmit load spikes from higher-power cards, cards will crash.
Mm. I think that was mentioned before but I couldn't find the source?
Thanks!
So just to clarify, no issues with any of the ath9k boards? But it sounds like one could be pushing it on 802.3af on the 560 AP?
i.e. above i'm not talking the 3.3v supplies for the radios but total 802.3af/at power consumption?
Thanks for prompting me to have another look at what we're talking about.
Regarding the power limits. Apologies regarding my earlier comment, I was thinking / talking in terms of the transient behaviour of the converter, not from the perspective of max current.
To clarify: I think we're talking pure over current not any sort of transient behaviour in the 3.3v converter when talking modern mt7915 4T4R cards. Without reverse engineering the converter, I'm guessing they just specified it for much less powerful radios.
Looking at an asiarf 7915 4T4R board, it needs 3.3V @ 3.3A, whilst the recommended is minimum 3.3v@2.5A?
AR9390 datasheet from what I can find is ~1A transmit max and 0.3A RX? Couldn't find much info. Not thinking about newer cards that draw 2-3x the power seems reasonable. That would require a much bigger inductors, transistors etc.
I think it was mentioned that perhaps 1 7915 board could work except for some transients which makes sense? ~2A is close to 2.5A i guess it could work.
