Sounds fair. However, it mentions to only support SLC NAND devices up to 4 Gbit while the MX65 has an 8 Gbit. Not sure whether that is a hard limit though. Plus I don't know anything about the software side of things for that programmer. Likely Windows only but clicking on their link gives a 404.
Maybe they do have at least console-only Linux software. And BTW that one is USD 40.- new here plus the socket USD 18.- if I am not mistaken.
Likely Windows only but clicking on their link gives a 404
Glad you checked. The 404 is enough to make me not want to bother with it, and any windows requirement will be a refusal as I don't have any computers that will ethically run win10 or 11 and using a VM tends to be a bit of a hassle when trying to pass-through USB devices unless I buy a dedicated (not MB based) controller just for the VM to use. IMO, using linux or BSD on one's workstation is all around less hassle when working with embedded devices that also run some manner of linux or BSD.
Anyway, I looked into the NAND a bit closer and obtained the spec sheet for it: [download link], confirming it needs a "48-pin TSOP type 1, CPL" compatible device.
As far as supported NAND compatibility with the FlashcatUSB_XPORT, here's some conversion of part numbers. The "(A)" below is assumed as SLC on both "supported" and "mx65 boot listed" since it's the only option in the Micron spec sheet, but the MX65 explicitly has "A" in that sequence of part numbering, where as the FlashcatUSB_XPORT page lists the supported Micron NAND part number without the "A". Some additional "single value option" values are also assumed in the part number from Flashcat, which I've listed below.
When converting and comparing the rest of the part number values between MX65 boot output and the supported Micron NAND, it seems the only difference is 2 die supported by Flashcat vs 1 die being used on the MX65 NAND.
FlashcatUSB_XPORT Supported NAND:
Listed: MT29F8G08DAA (4Gbit):
Spec Chart: MT29F8G08-(A)[D]-{A}(C)%A%
(A) = SLC implied as only option
[D] = 2 Die
{A} = 3.3V
(C) = implied "feature set C" as only option
%A% = Async interface
MX65 boot output part number for NAND:
Listed: MT29F8G08ABACA
Spec Chart: MT29F8G08-(A)[B]-{A}(C)%A%
(A) = SLC explicitly listed
[B] = 1 Die
{A} = 3.3V
(C) = explicitly listed "feature set C"
%A% = Async interface
So, 1 die vs 2 die being the only difference on those part numbers, I assume it mean the FlashcatUSB_XPORT is an appropriate device to purchase. Is that a valid assumption to make here?
Edit: looked around on their products page a bit longer and I see that the full part number for the MX65 NAND is supported by the FlashcatUSB-Mach1, so I'll purchase that one.
Parts update... the following are on their way to get this bricked NAND back to hopefully operational status. I'll keep working on the two non-bricked MX64 units in the interim, but right now the one thing I'm having a challenging time locating is the UNI-48-CLIP device itself.
If anyone knows of a USA based supplier that has the UNI-48-CLIP in stock please let me know. Aliexpress is ok in some cases but the delivery timelines conflict with some summer plans an I'd like to get cracking on this NAND sooner than August.
Part numbers just ordered and pending shipment here in the screenshot... very excited. New hardware right now is basically Christmas in July.
Quick update on the linked initramfs and sysupgrade files. I added those to the USB drive, rebooted the MX65 with reset held down as usual, got the white LED, released, and the initramfs loads as follows:
reading openwrt-bcm53xx-generic-meraki_mx65-initramfs.bin
..........[more loading time here, dots redacted from paste] ....
10917144 bytes read
## Booting kernel from FIT Image at 90000000 ...
Using 'config@3' configuration
Trying 'kernel-1' kernel subimage
Description: ARM OpenWrt Linux-5.15.45
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x900000e4
Data Size: 10898926 Bytes = 10.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x60008000
Entry Point: 0x60008000
Hash algo: crc32
Hash value: 93f563e8
Hash algo: sha1
Hash value: 04e121c2ec18ad996b54765a0e16fd1054739fea
Verifying Hash Integrity ... crc32+ sha1+ OK
Boot then proceeds to the kernel image and seems to stall at the decompression stage:
## Flattened Device Tree from FIT Image at 90000000
Using 'config@3' configuration
Trying 'fdt-1' FDT blob subimage
Description: ARM OpenWrt meraki_mx65 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x90a6500c
Data Size: 16334 Bytes = 16 KiB
Architecture: ARM
Hash algo: crc32
Hash value: 66288068
Hash algo: sha1
Hash value: 5ddfb4ef871bbd96d14156401b47047f54083540
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x90a6500c
Uncompressing Kernel Image ...
I've left the system running for >30 min to see if the decompression requires a longer time than I'd expect, but so far it will only sit there on TTY output with no further updates.
FWIW, this is all occurring while the USB drive is plugged during boot.
BusyBox v1.35.0 (2022-07-08 13:59:30 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r19791+247-f4415f7635
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/# uname -r
5.10.127
root@OpenWrt:/# date
Fri Jul 8 14:23:13 UTC 2022
root@OpenWrt:/#
@clayface a couple questions about expected versions of u-boot, initramfs, and kernel after the sysupgrade process.
Sequence of events:
My previous paste of the boot sequence that displays OpenWrt ascii art shows the following versions, which was after copying the latest openwrt-bcm53xx-generic-meraki_mx65-initramfs.bin over to USB and then having the drive in its USB motherboard port during a reboot-reset-hold cycle.
U-Boot version: 2012.10 (May 04 2022 - 23:46:39)
Snapshot version: r19791+247-f4415f7635
Kernel version: 5.10.127
After booting the above, I followed the upgrade instructions of copying the openwrt-bcm53xx-generic-meraki_mx65-squashfs.sysupgrade.bin file via scp from a connected laptop (using the 192.168.1.x/24 network addressing as per usual.
Upgrade process completes successfully and I set a root password, then connect ethernet to the first LAN port to the host laptop.
I check the webUI and it shows the typical main page, except at the bottom it lists the running versions as Powered by LuCI custom_mx65 branch (git-22.137.71281-d6dbedd) / OpenWrt SNAPSHOT r19791+44-f4415f7635
Seems fine as far as functionality is concerned, so I remove the usb drive and issue a soft reboot
MX65 boots up and looks good over TTL
Boot cycle completes and displays the ascii art banner, but this time the versions are as follows:
After grep'ing the minicom log capture files I see the u-boot version is consistently the same 2012.10 (May 04 2022 - 23:46:39), the only time it was not as such as when the original loader was present (U-Boot 2012.10-00101-g93bc206 (Jun 19 2015 - 12:33:28))
So... before I move on to flashing another MX65 sitting here at my desk, is the above version info expected? Here are the file hashes that correspond to the files on the USB drive that was used, which includes the most recent initramfs from the box.com link.
Hi all,
I compiled the openwrt from scratch and finally I have my MX65 running but IĀ“m not able to bring up the poe interfaces (LAN11 ,LAN12) .
I would like connect a coupe of Cisco AP on those interfaces but no lucky for he moment.
Any ideas?
Thanks
Afterwards, transfer the debug log via scp from the mx65 to a laptop/workstation and then upload the file contents to a pastebin style site, and provide the URL for review.
Additionally, if you can provide the commands and config you used to build openwrt that would be helpful.
The PR doesn't include POE support because of the PSE firmware/driver issue. I have patched in what is provided from the Meraki GPL archive in a different branch which you can build instead, until a solution is in place.
This all looks fine. While I suggest you compile your own image with the features you need, you can use this one which is updated from 5.15.45 to 5.15.53.
Indeed, I'm setting up a dev environment for openwrt this week along with some build automation. I somehow managed to sit and page through the list of 9000+ packages while keeping track of the additional ones I need along with notes on kernel module requirements for the package installs which failed dep checks. I'll reference your mx65_custom branch as a starting point, unless there are suggestions for an alternate approach.
Can someone give me the procedure for updating Meraki MX64-A0 with locked mtd0 from OpenWrt-BCM5862x image to OpenWrt-BCM53xx image? I tried several times but without success.
Putting together a build environment is not super-easy! If anyone reputable on this forum has some spare time we would greatly appreciate a set of builds for the three known varieties of Meraki (two versions of MX64 and MX65)!
