jebuskrust
commented
6 years ago Also everything else is working great, Thanks for the amazing work guys! :) :heart:
Open jebuskrust opened 6 years ago
jebuskrust
commented
6 years ago Also everything else is working great, Thanks for the amazing work guys! :) :heart:
jebuskrust
commented
6 years ago Thanks for everything bud ♥️ you're awesome. Will post more later
chunkeey
commented
6 years ago That ubi0_0_diagnostic1 sha256sum matches. In order to extract the files:
# binwalk -e ubi0_0_diagnostic1
# cd _ubi_0_0-diagnostic1.extracted
# cpio -i < 5CFFCC (This will extract the diagnostic1 initramfs into the _ubi_0_0-diagnostic1.extracted directory.)
As for what we know about the CC2650. Here are some useful PDF from TI:
The ./cc2538-bsl.py tool identifies the chip as:
As for flashing the chip, I think these files are probably the most interesting in the diagnostics1 image: usr/sbin/senao_check_BLE_and_upgrade_OS.sh usr/sbin/senao_check_BLE_OS.sh usr/sbin/senao_upgrade_BLE_OS.sh
All three use devmem2 utility to toggle GPIO 12 (RESET_N pin) and GPIO 52 (supposedly the backdoor pin - see the Serial Bootloader Interface PDF!).
One issue with the CC2650 is that the backdoor gpio. The GPIO is also muxed as part of the QPIC NAND controller: See https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-mr33.dts#L345 :
There are 18 pins. 15 pins are common between LCD and NAND.
The QPIC controller arbitrates between LCD and NAND. Of the
remaining 4, 2 are for NAND and 2 are for LCD exclusively.
The meraki source hints that the bluetooth module claims
pin 52 as well. But sadly, there's no data whenever this
is a NAND or LCD exclusive pin or not.Edit: Since it was mentioned in the top post: ttyMSM0 is the main UART of the IPQ4029 SoC. It is connected to the very same pesky 1x4 low-profile header that you had to connect to during the initial openwrt flashing procedure (so it has no connection to the CC2650).
However, it looks like that next to the CC2650 on the MR33 PCB is a unpopulated 1x4 header. My guess is that can be used to directly hook up the CC2650 on the MR33 PCB to the TI DevKit.
chunkeey
commented
6 years ago Does anyone know if these partitions are unique or are the partitions identical between all MR33s? (for example does my MR33 have minor changes in the partitions with a serial number/mac address etc)
The content of the part.(safe/old/new) and rootfs-# partitions depend on the installed meraki firmware version/release. The storage partition will likely differ from device to device (since the firmware stores logs, caches and other stuff on there). The ART/Caldata should also be different for each device, since every device needs to be calibrated individually.
I've added a list of partitions and their sha254sums to my repo's README.md. If someone can confirm they are identical between all MR33s (using these hashes), I can upload the other partitions.
Yeah, the sums of the diagnostic1, part.safe, part.old, rootfs-25-...-1 and rootfs-25-...-2 matches mine. The ART is a little bit different.
Note: The serial number and Ethernet MAC is not stored in the NAND on the MR33! Instead these are located in the little at24c64 eeprom on i2c-0 @ 0x50. The content of it is accessible through the /sys/bus/i2c/drivers/at24/0-0050/eeprom file. you can make a copy of it if you want:
# cp /sys/bus/i2c/drivers/at24/0-0050/eeprom /tmp
# hexdump -C /tmp/eeprom
# scp /tmp/eeprom $user@$pc:/${mr33-backup-directory}/(That said, OpenWrt marks the eeprom as read-only in the dts. So it should be safe.) https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-mr33.dts#L155
chunkeey
commented
6 years ago (It got nuked?)
jebuskrust
commented
6 years ago I deleted the diagnostics partition while installing the first time. Document only said that the only partition that was needed was art. The install worked, its just I think I may need some stuff within diagnostics1 partition for bluetooth LE.
Everything else works.. the wifi radios , network adapter.. I have everything up and running.
jebuskrust
commented
6 years ago 
jebuskrust
commented
6 years ago If there's aproper way to restore this diagnostics partition, it would be neato cheato. I still have my original art partition. Just looking to see how to do it. I was able to extract everything and observe the python scripts and firmware hex files, al etc.
jebuskrust
commented
6 years ago This is what I got from the repo ;) and what I have matches
The marked out one will be my own art partition since i kept it. If I'm able to restore.
Cheers,
A handy doc showing how to restore these in the future would be great.
And thanks again!
jebuskrust
commented
6 years ago Sorry posted the md5sums intentionally meant to say. lol checked the sha256s prior lmao
jebuskrust
commented
6 years ago Looks like I am going to have to do this from first boot /uboot because I can't whack the root (data needs to go)partitions via ubi commands since they are attached currently lol 🤣. Not enough space to restore the diagnostic partition. I should be able to whack then
jebuskrust
commented
6 years ago Sweet well that was successful. Back up and running again.
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 137 LEBs (17395712 bytes, 16.6 MiB)
State: OK
Name: diagnostic1
Character device major/minor: 247:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: static
Alignment: 1
Size: 48 LEBs (6094848 bytes, 5.8 MiB)
Data bytes: 6090888 bytes (5.8 MiB)
State: OK
Name: part.old
Character device major/minor: 247:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 25 LEBs (3174400 bytes, 3.0 MiB)
State: OK
Name: part.safe
Character device major/minor: 247:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 21 LEBs (2666496 bytes, 2.5 MiB)
State: OK
Name: rootfs
Character device major/minor: 247:4
-----------------------------------
Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 636 LEBs (80756736 bytes, 77.0 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 247:5
-----------------------------------
-----------------------------------
Volume ID: 6 (on ubi0)
Type: dynamic
Alignment: 1
Size: 5 LEBs (634880 bytes, 620.0 KiB)
State: OK
Name: ART
Character device major/minor: 247:7
Hopefully Im not missing anything else now, will see tomorrow. Have to put the kids to bed.. thanks again! :)
chunkeey
commented
6 years ago (Did another post [this time from @jebuskrust ] get nuked?)
jebuskrust
commented
6 years ago I deleted it. I was able to load the firmware into it using the cc2536-bsl tool =) I was also able to get the hd0 interface to finally come up as well.
The post i deleted was related to the devmem2 app. I was able to recompile it so it would run on the mr33 openwrt build that I installed. Not sure if it works correctly but its built.
However it wont work, it depends on /dev/mem
Missing CONFIG_DEVMEM=y in the kernel configuration for the device.
chunkeey
commented
6 years ago Missing CONFIG_DEVMEM=y in the kernel configuration for the device.
Hm, openwrt has this as a config option: CONFIG_KERNEL_DEVMEM https://github.com/openwrt/openwrt/blob/master/config/Config-kernel.in#L775
but any free (as in unclaimed) gpio can be set via the "GPIO Sysfs Interface for Userspace": https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
from userspace. The memory addresses of 100c000 and 1034000 match the configuration registers for the pinctrl for gpio12 and gpio52. The usr/sbin/senao_check_BLE_and_upgrade_OS.sh scripts sets gpio52 to output and then high. Next gpio12 is set to output, low and then to high.
The ipq4019's pinctrl code has all the registers and bit definitions. So if someone is interested, all the information is there.
Leo-PL
commented
3 years ago I'm trying to get Bluetooth running on upstream OpenWrt 19.07 build. But for some strange reasons:
hciattach /dev/ttyMSM1 any 1500000 flow shows timeouts visible in kernel log when attempted - I guess it's not surprise at all, given the above.bluetooth node to ti,cc2560 - which is actually present in the driver, despite the fact it's a different chip - I just haven't found DT bindings for generic HCIUART driver. @chunkeey maybe the compatible string should be changed?My first suspicion was, that I'm missing a pinctrl entry for GPIO12, but in https://github.com/riptidewave93/LEDE-MR33/blob/43ca7f34e0437ef9384fc38f1c4de6a843f1dd98/overlay/target/linux/ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4029-mr33.dts I don't see any, only changes being adding RTS/CTS for UART1. Also, do I need to reflash CC2650 first, or should it run HCI firmware from stock SW already? Do you recall any "magic incantations" I need to perform in addition to the above to communicate with CC2650?
chunkeey
commented
3 years ago @Leo-PL , I think you are running up the issue that the CC2650 is not a full bluetooth chip. As explained in: https://github.com/riptidewave93/LEDE-MR33/issues/7#issuecomment-387164702
The cc2650 (in the Meraki) is not a full bluetooth chip. It only supports bluetooth >LE< and needs a firmware to switch between the client/server modes.
the (current) bluez tools (hcitool/hciattach/...) do not really support these pure/only bluetooth LE chips. That's why, if you look into the original meraki MR33 firmware, you'll see that Meraki made custom tools (blescan) to deal with these devices.
Granted, this was the situation back in 2018. No idea if the hcitool/hciattach now has support for these special CC2650 (they are different from the CC2560 - but I remember that the 56<->65 transposed digits had me plenty confused as well.).
Leo-PL
commented
3 years ago So it was PEBKAC problem after all. Too bad that I nuked my original FW dump already. I guess, to make this chip actually usable, a custom firmware implementing HCI bridge would be needed. Good side of this is, that the chip also supports Zigbee as well, so it could in theory be used to act as a bridge for that as well, but all of that would be a lot of effort.
Leo-PL
commented
3 years ago At least, what I managed to find out is to verify, that GPIO52 isn't used by NAND controller - it would make no sense to share it with NAND-flash as a GPIO used for reset - given the way NAND interface works. I took a peek at IPQ4019 datasheet available at the usual sources, and for it, GPIO52 doesn't have an alternate function for QPIC on that one - and these are more-or-less sibling chips.
I successfully booted the unit and verified NAND operation without GPIO52 included in nand_pins pinctrl node.
Regarding exposing HCI interface from CC2650, I found an example in TI documentation, that does just that - I'll look into it soon, hopefully. TL;DR is that host_test example implements LE commands over HCI UART - in a pure network processor fashion.
Source: https://www.ti.com/lit/ug/swru393e/swru393e.pdf, section 5.7.
Trying to get the Bluetooth working and having some issues.
Question:
1- Do I have to compile a custom toolchained build of openwrt to get bluetooth LE working based off of the commit on the README of the repo? Or is it currently part of original kernel that makes up snapshot of the installation and or latest snapshots on openwrt's website snapshot development builds?
I have the two present devices which appears that the device is actually there. /dev/ttyMSM0 (not it) /dev/ttyMSM1 (this is it)
Ive tried the following
I do not believe I have the diagnostics1 partition. I nuked all of them when going through the guide. This partition appears to have some shell scripts and an BD (backdoor enabled) hex file that's potentially needed. I know its not recoverable, however, Is it possible to obtain it from someone?
So now i've gone ahead and factory reset the unit, and i'm using the base image which was provided in the original flash process documentation.
https://github.com/riptidewave93/LEDE-MR33/commit/43ca7f34e0437ef9384fc38f1c4de6a843f1dd98#diff-ca06bdc419700627c349fe322c116910
Heres what dtc shows when checking the device tree information outputted in dts format.
`root@MR33:/# dtc -I fs -O dts /sys/firmware/devicetree/base Warning (unit_address_vs_reg): Node /soc/ad-hoc-bus has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name /dts-v1/;
/ { compatible = "meraki,mr33", "qcom,ipq4019"; model = "Meraki MR33 Access Point"; interrupt-parent = <0x1>;
address-cells = <0x1>;
}; `