How I revived the device (BH-USB-560v2 JTAG emulator) via U-Boot
I have doubts that the JTAG emulator for debugging processors from Texas Instruments is so common a device that its reanimation would be interesting to someone. However, the article may be useful to those who are trying to reanimate something based on a single-board device with Linux, having limited resources and information. You can consider this as some kind of practical work with U-Boot.
Instead of the preface
Those who debug programs for embedded systems know that you need to use special devices to connect to processors. For the Texas Instruments processor family, adapters called JTAG emulators are used.
There are many, and from different manufacturers. In my park, among other things, Blackhawk USB560v2 is listed. I must admit, not the cheapest piece of hardware. Then one day she stopped working for no apparent reason.
Symptoms
It all happened one day, the device just stopped loading and being detected via USB. The LED blinked, but did not go into the "ready for use" state.
This device has an interesting documented mode: after 10-15 unsuccessful downloads, it should have gone into a special mode (safe mode) that would allow it to be reflashed. However, my device refused to switch to this mode, it did not reach the USB numbering stage, and therefore there was no opportunity to reflash with the standard utility. Correspondence with the support service didn’t lead to anything: they refused to help me with the equipment, only offering to send (at their own expense) a device to the USA for diagnostics and repair.
There was nothing left to do but how to proceed with self-repair.
Ubuntu is installed on the host, some utilities are included in the distribution, some are installed via apt.
Visual inspection
We disassemble, we look at the board. On the board are located:
- TI TMS320DM6441 microprocessor
- Flash Micron MT29F1G08ABBDAHC
- 2x DRAM Micron MT47H64M16HR-3
- FPGA Altera MAX II (EPM570GF00C5N) and Cyclon III (EP3C25U256C8N)
I was particularly pleased with the carefully-designed UART connector, which was not only diluted with a standard 2.54 mm comb, so the contacts were also signed. This I have not seen for a long time, a maximum of Piglet on the board, and even with meaningless markings such as TP1, etc.
Let's get started
We connect USB-UART (do not forget about the level, it is 3.3 V here). Run minicom, we get:
TI UBL Version: 1.13, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0000002C Device ID = 0x000000A1 Pages Per Block = 0x00000040 Number of Blocks = 0x00000400 Bytes Per Page = 0x00000800 Valid MagicNum found at block 0x00000001, page 0x00000008 NAND Boot success. DONE U-Boot 2010.12 (May 09 2012 - 13:10:23) Cores: ARM 257 MHz, DSP 513 MHz DDR: 162 MHz I2C: ready DRAM: 256 MiB NAND: 128 MiB MMC: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In: serial Out: serial Err: serial Read USBID pin : DEVICE Read boot progress legacy : 0 Read boot progress : 0 Write boot progress legacy : 0 Write boot progress : 0 Hit any key to stop autoboot: 0 Loading from NAND 128MiB 1,8V 8-bit, offset 0x60000 Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 NAND read from offset 60000 failed -74 ** Read error ## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! As you can see, the sequence is quite standard: first the bootloader (TI UBL) is loaded, then the U-Boot, which in turn loads the Linux kernel.
According to the log, it is obvious that something has flown in the internal NAND Flash, when the Linux kernel loads, the checksum does not converge. However, you can interrupt the download and enter the U-Boot console.
See available commands:
U-Boot > help ? - alias for 'help' askenv - get environment variables from stdin base - print or set address offset boot - boot default, ie, run 'bootcmd' bootd - boot default, ie, run 'bootcmd' bootm - boot application image from memory cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo - echo args to console editenv - edit environment variable eeprom - EEPROM sub-system env - environment handling commands exit - exit script false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) go - start application at address 'addr' help - print command description/usage i2c - I2C sub-system iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mdc - memory display cyclic mii - MII utility commands mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - display MMC info mtest - simple RAM read/write test mw - memory write (fill) mwc - memory write cyclic nand - NAND sub-system nboot - boot from NAND device nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage saves - save S-Record file over serial line setenv - set environment variables showvar - print local hushshell variables sleep - delay execution for some time source - run script from memory test - minimal test like /bin/sh true - do nothing, successfully usb - USB sub-system usbboot - boot from USB device version - print monitor version Let's look at the environment variables:
U-Boot > printenv autokern=0x60000 autoroot=/dev/mtdblock3 baudrate=115200 bootcmd=nboot 80700000 0 ${autokern}; run setbootargsnand; bootm setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off stderr=serial stdin=serial stdout=serial ver=U-Boot 2010.12 (May 09 2012 - 13:10:23) Environment size: 338/16380 bytes First of all, I tried to disable the scan and boot using U-Boot commands.
U-Boot > setenv verify n U-Boot > boot Proved a little further, but not much:
## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux................................................................................. crc error te Then the device hangs.
It is clear from the environment variables that the kernel image lies in NAND Flash with an offset of 0x60000, is loaded at address 0x80700000 (according to the processor’s memory map, this is the address space of the external DRAM memory) and is loaded. The size of the kernel image, as can be seen from the log, is 123,692 bytes. I tried to do it manually. We assume that the image is stored in the uImage format, so we throw 64 bytes on the header, we get 1236356 bytes = 0x12DD84:
U-Boot > nand read 80700000 60000 12dd84 U-Boot > iminfo ## Checking Image at 80700000 ... Legacy image found Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... Bad Data CRC Then I wanted to dump the image to the computer to play with it. I didn’t come up with anything better than how to write a console log with memory output to the screen, and then convert it into a binary file.
Run minicom with a log entry:
minicom -C orig-uImage.txt We display the contents of the memory on the screen:
U-Boot > md.b 80700000 12dd84 Exit the minicom, edit the log, remove the extra lines, convert it into a binary:
xxd -r -seek -0x80700000 orig-uImage.txt orig-uImage I wanted to repack the image so that it does not give out checksum errors. Delete the first 64 bytes and then make a new uImage:
mkimage -A arm -T kernel -C none -a 80008000 -e 80008000 -n "Linux-2.6.10_mvl401-xds560" -d orig-uImage patched-uImage Fill the resulting file back using the YModem protocol:
U-Boot > loady ## Ready for binary (ymodem) download to 0x80700000 at 115200 bps... C## Total Size = 0x0012dd84 = 1236356 Bytes U-Boot > iminfo ## Checking Image at 80700000 ... Legacy image found Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK We try to boot, but also hang on the stage of unpacking the kernel:
U-Boot > bootm ## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux................................................................................. crc error te It is quite expected, on what one could hope for. But at least pumped up the file-sharing file transfer, already not bad.
All we have is the firmware file from the manufacturer’s website , USB560v2_firmware_5.0.573.0.bin . I assumed that this file contains a kernel image, but it would be reasonable to expect that the file is encrypted with at least a simple key. Therefore, I confess, I broke down and wrote to the manufacturer a request to give me an unbeaten uImage so that I flooded it into the device and booted from it, and then I could reflash the device with a regular USB utility. He even referred to the terms of the GPL (under which Linux is distributed), according to which it would not hurt in addition to provide the kernel source codes.
Immediately after sending the request, I decided to try to unpack the firmware file as a simple archive. And, lo and behold, it turned out!
tar -xf USB560v2_firmware_5.0.573.0.bin After unpacking, two files appeared: uImage and rootfs.tar.gz . What the doctor has prescribed is the kernel image and the root file system.
It remains to fill the uImage into the device's memory by YModem and start, which I did. The device successfully booted into that very safe mode, I hung up those. backed by the manufacturer and, thinking that I’m going to get the device next time, I calmly went to bed.
Second series
However, the next day I was in for an unpleasant surprise. The device has stopped loading successfully. What I just did not try, I got an error:
INIT: PANIC: segmentation violation! sleeping for 30 seconds. Starting kernel ... Uncompressing Linux................................................................................. done, booting thelLinux version 2.6.10_mvl2 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback Built 1 zonelists Kernel command line: mem=64M console=ttyS0,115200n8 root=/dev/mtdblock3 rw rootfstype=jffs2 ip=off PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB = 64MB total Memory: 62080KB available (2118K code, 448K data, 136K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok spawn_desched_task(00000000) desched cpu_callback 3/00000000 ksoftirqd started up. desched cpu_callback 2/00000000 desched thread 0 started up. NET: Registered protocol family 16 Registering platform device 'nor_davinci.0'. Parent at platform Registering platform device 'nand_davinci.0'. Parent at platform DaVinci I2C DEBUG: 12:46:30 Mar 29 2012 Registering platform device 'i2c'. Parent at platform musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [peripheral] [debug=0] Registering platform device 'musb_hdrc'. Parent at platform musb_hdrc: USB Peripheral mode controller at c4800000 using DMA, IRQ 12 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. yaffs Mar 29 2012 12:46:15 Installing. Registering platform device 'davincifb.0'. Parent at platform Console: switching to colour frame buffer device 90x30 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled Registering platform device 'serial8250'. Parent at platform ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize Registering platform device 'ti_davinci_emac'. Parent at platform TI DaVinci EMAC: MAC address is 00:00:00:04:12:64 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. netconsole: not configured, aborting i2c /dev entries driver elevator: using anticipatory as default io scheduler NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Unknown NAND 128MiB 1,8V 8-bit) Scanning device for bad blocks Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging" nand_davinci: hardware revision: 2.1 mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET: Registered protocol family 1 NET: Registered protocol family 17 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000016c: 0xffef instead Empty flash at 0x00a237fc ends at 0x00a23800 Empty flash at 0x00c3b7d8 ends at 0x00c3b800 mtd->read(0x1f320 bytes from 0xec0ce0) returned ECC error mtd->read(0x1fb8c bytes from 0xf20474) returned ECC error VFS: Mounted root (jffs2 filesystem). Freeing init memory: 136K mtd->read(0x44 bytes from 0xf39da8) returned ECC error mtd->read(0x988 bytes from 0xf39420) returned ECC error mtd->read(0x44 bytes from 0xed8d20) returned ECC error jffs2_get_inode_nodes(): Data CRC failed on node at 0x00ed8d20: Read 0xa8462b94, calculated 0xa03c90e8 mtd->read(0xa7e bytes from 0xed82a0) returned ECC error jffs2_get_inode_nodes(): Data CRC failed on node at 0x00c3ad78: Read 0x31ac7e30, calculated 0xa52ecb11 jffs2_get_inode_nodes(): Data CRC failed on node at 0x00a22d9c: Read 0x31ac7e30, calculated 0xe9f89c4c mtd->read(0x988 bytes from 0xf39420) returned ECC error mtd->read(0xa7e bytes from 0xed82a0) returned ECC error INIT: version 2.85 booting INIT: PANIC: segmentation violation! sleeping for 30 seconds. jffs2_get_inode_nodes(): Data CRC failed on node at 0x00a2ad10: Read 0x5fa921cc, calculated 0x5282f1d9 INIT: PANIC: segmentation violation! sleeping for 30 seconds. I concluded that the root filesystem was also damaged. Well, then you need to flash it too.
First, we write uImage to NAND in order not to load every time through UART (I must admit, at a speed of 115200 a file, even the size of one megabyte, can be loaded for a considerable time). When working with NAND, just in case, we align the size of the image to the size of the NAND page in a big direction (somewhere I met such a recommendation), and the page size is 1024 bytes = 0x800 (see the very first log).
U-Boot > loady ... U-Boot > nand erase 60000 12DC00 U-Boot > nand write 80700000 60000 12DC00 From the kernel boot log, we extract useful information:
Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging" So the root filesystem must be written to NAND with an offset of 0x260000. It remains only to understand in what format. We recall about the U-Boot environment variables, in particular, about this line:
setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off So, we need to convert our rootfs.tar.gz , extracted from the firmware file, into the JFFS2 format. At the prompt with Texas Instruments' Wiki, we do this ( sudo needed for tar , so without it it gives errors when running the mknod command):
mkdir rootfs sudo tar -xf rootfs.tar.gz -C rootfs mkfs.jffs2 -n -r rootfs -e 16 -o rootfs.jffs2 We load the resulting file into the device’s memory, and then copy it to the desired NAND site (we also round it to the page):
U-Boot > loady ... U-Boot > nand erase 260000 39f000 U-Boot > nand write 80700000 260000 39f000 We cross our fingers, reboot, well, now everything is just fine.
TI UBL Version: 1.13, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0000002C Device ID = 0x000000A1 Pages Per Block = 0x00000040 Number of Blocks = 0x00000400 Bytes Per Page = 0x00000800 Valid MagicNum found at block 0x00000001, page 0x00000008 NAND Boot success. DONE U-Boot 2010.12 (May 09 2012 - 13:10:23) Cores: ARM 257 MHz, DSP 513 MHz DDR: 162 MHz I2C: ready DRAM: 256 MiB NAND: 128 MiB MMC: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In: serial Out: serial Err: serial Read USBID pin : DEVICE Read boot progress legacy : 3 Read boot progress : 10 Write boot progress legacy : 2 Write boot progress : 9 Hit any key to stop autoboot: 0 Loading from NAND 128MiB 1,8V 8-bit, offset 0x1260000 Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1235632 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 ## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1235632 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux................................................................................. done, booting thelLinux version 2.6.10_mvl2 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback Built 1 zonelists Kernel command line: mem=64M console=ttyS0,115200n8 root=/dev/mtdblock5 rw rootfstype=jffs2 ip=off PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB = 64MB total Memory: 62080KB available (2118K code, 448K data, 136K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok spawn_desched_task(00000000) desched cpu_callback 3/00000000 ksoftirqd started up. desched cpu_callback 2/00000000 desched thread 0 started up. NET: Registered protocol family 16 Registering platform device 'nor_davinci.0'. Parent at platform Registering platform device 'nand_davinci.0'. Parent at platform DaVinci I2C DEBUG: 12:46:30 Mar 29 2012 Registering platform device 'i2c'. Parent at platform musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [peripheral] [debug=0] Registering platform device 'musb_hdrc'. Parent at platform musb_hdrc: USB Peripheral mode controller at c4800000 using DMA, IRQ 12 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. yaffs Mar 29 2012 12:46:15 Installing. Registering platform device 'davincifb.0'. Parent at platform Console: switching to colour frame buffer device 90x30 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled Registering platform device 'serial8250'. Parent at platform ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize Registering platform device 'ti_davinci_emac'. Parent at platform TI DaVinci EMAC: MAC address is 00:00:00:04:12:64 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. netconsole: not configured, aborting i2c /dev entries driver elevator: using anticipatory as default io scheduler NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Unknown NAND 128MiB 1,8V 8-bit) Scanning device for bad blocks Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging" nand_davinci: hardware revision: 2.1 mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET: Registered protocol family 1 NET: Registered protocol family 17 mtd->read(0x400 bytes from 0x0) returned ECC error VFS: Mounted root (jffs2 filesystem). Freeing init memory: 136K INIT: version 2.85 booting 0 Mounting local filesystems: mount none on /var/log type tmpfs (rw,size=2M) none on /var/lock type tmpfs (rw) none on /var/run type tmpfs (rw) INIT: Entering runlevel: 3 /etc/rc.d/rc3.d/S88davinci_mmc: 69: /usr/local/bin/sd_app: not found Registering platform device 'mmc0.1'. Parent at platform : Supporting 4-bit mode /etc/rc.d/rc3.d/S90fsemulator: 72: /usr/local/bin/sd_app: not found bh560v2u gadget: Blackhawk USB560v2 System Trace Emulator, version: 1.00 bh560v2u gadget: using musb_hdrc, OUT ep1out IN ep1in bh560v2u gadget: DTC-USB device attached to major/minor numbers 254 0 /etc/rc.d/rc3.d/S93dsplink: 69: /usr/local/bin/sd_app: not found bh560v2u gadget: high speed config #1: High-speed configuration dsplinkk: no version for "struct_module" found: kernel tainted. DSPLINK Module (1.51) created on Date: Mar 29 2012 Time: 12:48:55 /etc/rc.d/rc3.d/S95fpgaprog: 72: /usr/local/bin/sd_app: not found Device '/dev/mem' opened successfully. Turned off Debug Clock Turned off Trace Clock FPGA erased successfully FPGA data length=460284 Device '/dev/mem' opened successfully. Programming FPGA: FPGA Image CRC=39550, FPGA programmed CRC=28013 Turned on Debug Clock Turned on Trace Clock Device #1 IDCODE is 020F30DD configuring SRAM device(s)... DONE Exit code = 0... Success /etc/rc.d/rc3.d/S96dtc_main: 70: /usr/local/bin/sd_app: not found MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980) (none) login: emac_control:4584[0]ioctl called when device is NOT open<3>ERROR: davinci_emac: eth0 error: Error 3000000E from EMAC TX Channel O) SIOCSIFHWADDR: Input/output error Failed to reset boot progress: dtc_periph_lock.cpp(78) : timeout : /var/lock/i2c MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980) 00:00:00:04:12:64 login: root Welcome to MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980). login[825]: root login on `console' # Afterword
Yes, the final procedure was not very complicated, there is really little real reverse engineering here. But I personally learned a lot of new things about low-level things during the boot process of embedded Linux, learned to work with the U-Boot console.
It is evident that the guys did not bother with protection. After loading Linux in the console, you are prompted to login. Login root without a password allows you to log in with administrative access and do whatever you want with the device. The most interesting is contained in the /usr/local/bin .
But that's another story.
I hope it was interesting.
')
Source: https://habr.com/ru/post/420895/
All Articles