This is an old revision of the document!
Table of Contents
Polycom Pano Hax
Bringing Linux and Other Operating Systems to the Polycom Pano.
Work in progress, no end-user guide yet!
Hardware
Jetson TX1 module + Polycom carrier board.
TX1
Stock module, 4GiB LPDDR4, 16GB eMMC. Production-fused.
I/O
| Port | Description |
|---|---|
| 2x GbE | 1x PoE, in wired to on-board USB3-ethernet adapter, 1x Non-PoE port wired directly to TX1-internal USB3-ethernet adapter |
| 2x USB | USB A 2.0 (OTG, upper) + USB A Super Speed |
| HDMI Out | Directly from TX1 |
| HDMI In | Through ??? under a metal can. |
| DC In | 5.5×2.5(?), Labeled 54VDC, runs from 36VDC min. |
| WiFi? Antenna | Built-in Jetson TX1 2.4 + 5G WIFI + Bluetooth radio |
| Button | Capacitive touch + RGB indicator LED |
| Header | Description |
|---|---|
| SW1102 RECOVERY | Internal RCM button |
| SW1101 RESET | Internal SoC Reset button |
| J901 SERIAL | Pinout: 1.8V, TX, GND, RX. Mind the logic 1.8V levels! 1.8V line dips when RESET button is pushed down. |
| TP1201 | Unmarked 12V DC rail test point (between AON_P5VO and T1502 transformer), can be used to power up the device directly (bypasses PoE/DC IN circuit), boots from ~11V DC |
Stock Software
It's running highly customized Android.
Serial port exposes password prompt. Unencrypted update bundle from Polycom/HPE reveals default password: EyZeBuYTQ - this should land a user shell, from which su just gets you root access.
“Devfeatures” (disabled iptables firewall, enabled adb, disabled serial password, enabled telnet I think) can be enabled via fw_setenv devfeatures true. fw_printenv can be used to check current environment variables.
Jetson TX1 is SecureBoot/Production-fused. Standard CBoot (first-stage bootloader) is unlocked ie. it does not do any signature verification over loaded boot partition or the operating system altogether.
Flash Layout
| Number | Start | Size | Name | Description |
|---|---|---|---|---|
| 1 | 17.4kB | 2097kB | BPF | BPMP Firmware? |
| 2 | 2115kB | 262kB | TBC | CBOOT 1st stage? |
| 3 | 2377kB | 262kB | TBC-B | CBOOT 1st stage backup? |
| 4 | 2639kB | 2097kB | EBT | CBOOT |
| 5 | 4736kB | 2097kB | RBL | CBOOT backup? same contents as EBT |
| 6 | 6833kB | 2097kB | NCT | |
| 7 | 8930kB | 6291kB | WB0 | “Warm Boot Firmware?” |
| 8 | 15.2MB | 2097kB | DFI | all 0x00 |
| 9 | 17.3MB | 4194kB | RP1 | DTB for CBOOT |
| 10 | 21.5MB | 4194kB | RP2 | 0x24 random bytes, then 0x00 |
| 11 | 25.7MB | 6291kB | TOS | “Trusted OS” |
| 12 | 32.0MB | 80.9kB | EKS | “Encrypted Key Storage” |
| 13 | 32.1MB | 2097kB | UKS | all 0x00 |
| 14 | 34.2MB | 2097kB | FB | all 0x00 |
| 15 | 36.3MB | 134MB | BMP | Splashscreen partition |
| 16 | 170MB | 26.7MB | SOS | Android Recovery image? |
| 17 | 197MB | 4194kB | DTB | DTB for Kernel |
| 18 | 201MB | 26.7MB | LNX | Android Boot image (“boot” fastboot partition) |
| 19 | 228MB | 2147MB | APP | ext4 /system |
| 20 | 2376MB | 2147MB | CAC | ext4 /cache |
| 21 | 4523MB | 805MB | vendor | ext4 /vendor |
| 22 | 5328MB | 2097kB | MSC | all 0x00 |
| 23 | 5331MB | 33.6MB | USP | all 0x00 |
| 24 | 5364MB | 2097kB | MDA | verity metadata partition |
| 25 | 5366MB | 8389kB | RP3 | empty ext4 |
| 26 | 5375MB | 8389kB | RP4 | all 0x00 |
| 27 | 5383MB | 16.8MB | FCT | empty ext4 |
| 28 | 5400MB | 8389kB | UCB | empty ext4, “touchscreen” and “mpu” directories |
| 29 | 5408MB | 2147MB | FAC | ext4 with “factory_restore.zip” update image applied when touch button is pressed on boot |
| 30 | 7556MB | 1074MB | PLC | ext4 with some polycom config stuff |
| 31 | 8629MB | 262kB | CRT | public/private key pair? |
| 32 | 8630MB | 7128MB | UDA | ext4 /data |
Flashing
Fastboot
Flashing is possible via Fastboot (implemented in cboot) over USB-A 2.0 connector (via cursed USB A-A or USB A-C connector). In order to enter Fastboot you can either:
reboot bootloaderfrom Android firmware- Use customized fusee-launcher with
force_fastboot.binpayload:./fusee-launcher.py -w -V 0x0955 -P 0x7721 force_fastboot.bin
QUIRK: Fastboot tends to crash/reset whenever HDMI Out is not connected to any display lmao.
RCM/TegraFlash
Alternative: tegraflash.py from L4T BSP.
NOTE: Latest L4T tooling doesn't really seem to work very well. Use R24.2.3. Issue seems to be with nvtboot_recovery.bin:
$ sha256sum */Linux_for_Tegra/bootloader/nvtboot_recovery.bin f3a54b2e29857ad627c6ae96352e8d1a2e9b538cca502f3565896c6f6cb51746 l4t24/Linux_for_Tegra/bootloader/nvtboot_recovery.bin # works 3d97c0c37201a5b98fabcc509ac57326bbde8076cee0b5294f969634d4b43a42 l4t28/Linux_for_Tegra/bootloader/nvtboot_recovery.bin # hangs cd6ec5b3c212fdc44d6d36e043448d2b3484749105005b612fcd043869bd53ac l4t32/Linux_for_Tegra/bootloader/nvtboot_recovery.bin # crashes with error 4
| Known Error | Reason |
|---|---|
[ 0.0221 ] Boot Rom communication failed Error: Return value 3 | Device is fused, needs fusee-launcher |
[ 0.0667 ] Cboot is not running on device. Error: Return value 4 | Device crashed, needs a reset (or different nvtboot_recovery.bin) |
As –bl use cboot from our device (mmcblk0p4).
./fusee-launcher.py -w -V 0x0955 -P 0x7721 ipatch_rcm_sample.bin python3 tegraflash.py --bl mmcblk0p4.img --applet nvtboot_recovery.bin --chip 0x21 --cmd "read DTB dtb-extracted.bin"
Booting Linux
Mainline U-Boot (d0615e4a67c commit tested) with p2371-2180_defconfig can be flashed over boot (mmcblk0p18) partition.
CROSS_COMPILE=aarch64-unknown-linux-gnu- make V=1 && \ mkbootimg --kernel u-boot.bin --pagesize 4096 --base 0x10008000 --output u-boot.aimg && \ fastboot flash boot u-boot.aimg && \ fastboot reboot